Saturday, October 18, 2008

Spliced feed for Security Bloggers Network

Spliced feed for Security Bloggers Network

Embedded Webapp Fun: NetScreen [HiR Information Report]

Posted: 18 Oct 2008 03:20 AM CDT

I like to tunnel SSH, whether it's for getting around a captive portal at an airport or for encrypting your traffic at DefCon.

At home, I use an old NetScreen1 5XP-Elite firewall. The "Elite" has absolutely nothing to do with its mad $k1llz. It just means it's got an unlimited network license, which is good because I have a lot of freaking computers in the Lab-O-Ratory.  

I wanted to run SSH over port 53 (DNS) as well as 22 to aid in tunneling SSH where external DNS is allowed (more often than you'd think) but I got this error via the GUI:

On the CLI, I was met with this:
ns5-> set vip untrust-ip 53 SSH
###Invalid reserved vip port number 53 for SSH service!
Well... CRAP!
I don't usually take "no" for an answer too easily. Some javascript told me I couldn't do it. Some little parameter within the CLI told me the same thing. I have a pretty hard time believing that the kernel of my firewall is incapable of spawning an SSH forward on port 53 when port 22 or 31337 would work just fine.  Skepticism of limitations is one of the fundamental elements of having the security mindset.

I poked through the web-page source code that renders the page, but it's all on-the-fly javascript. I decided that if I wanted to see what the form post was passing, it would be easier to sniff the session. I went ahead and fired up my old friend, Wireshark.2 

Notice that the web admin interface is only running on the internal interface, so I'm tunneling port 80 direct to it through one of my systems on the inside, hence the localhost:80 http session. I opted to redirect port 2201 to the internal SSH box, since it's well within the range of acceptable ports. I did a "Follow TCP Stream" and VOILA!


This gives me everything I need to make a quick HTML file that posts whatever port number I want as the "port" variable. I decided to take the easy way out and see if NetScreen's web interface would accept the variables as a GET, by pasting it into the location bar instead, just to see. I broke it up into three lines here, but you can see the only thing I changed was "2201" to "53".



What's the point? This was a practical example for how to putz around with stuff you may already have and dabble in the fascinating world of web application security.  As mentioned before, it's also an exercise in thinking beyond limitations.

Footnote 1:
NetScreen was founded by a bunch of ex-Cisco guys and the IOS-esque "ScreenOS" as it's called really shows it. In 2004, NetScreen was snarfed up by Juniper Networks. Juniper's low-end SSG-5 is about the closest living relative to my beloved yet crufty home firewall. 

Footnote 2:
On an odd side-note, Frogman and I got to see Gerald Combs (creator of the project now called Wireshark) give one of his very, very rare talks on TCP/IP, which included a lot of Ethereal's backstory.

Governator Vetoes Bill [TriGeoSphere]

Posted: 18 Oct 2008 02:27 AM CDT

The GovernatorCalifornia’s Governor, Arnold Schwarzenegger, vetoed the state legislator’s second attempt to pass a Consumer Data Protection Act.  While the new bill softened some provisions found in the original, such as the requirement that a breached organization reimburse financial institutions for the cost of replacing credit cards, it remained a flawed bill in many respects.

By vetoing the bill, the Governor once again concluded that adequate protection already exists. Schwarzenegger wrote, “As I stated in last year’s veto of a similar bill, this bill attempts to legislate in an area where the marketplace has already assigned responsibilities and liabilities that provide for the protection of consumers.”

I had a chance to talk about the proposed legislation last month. During the discussion, I expressed my hope that the Governor would again veto the bill because I saw it as an inadequate attempt to define appropriate data handling requirements with only one possible outcome…litigation.

The bill meant well, but falls short of providing any significant new value and includes minimal guidance on how to minimize the potential loss of data.  Its technical focus is limited to storage and transmission suggesting that businesses:
1.      Don’t store consumer data, even if it’s encrypted
2.      Encrypt data that is being transmitted on open networks

These aren’t unreasonable requests…

Inappropriate customer data storage and transmission have been the leading culprits in several recent breaches.  Unfortunately, storage and transmission breaches are only the tip of the iceberg.  Businesses continue to lose sensitive data just through wireless access points, weak passwords, weak encryption, vendor default or contractor passwords, systems compromised by key loggers, trojans and more.  Plain and simple: If a business handles a meaningful volume of credit card data, there is a high probability someone is looking for a way to get it.

Considering all the risks, and the reality that security can be expensive, don't we need legislation?

Perhaps… but not this legislation.

It didn't highlight many of the possible attack vectors and PCI already enforces everything the proposed legislation would offer. Given the California bill’s shortcomings, I wonder who the target audience was for the bill.  Were they serious about requiring businesses to protect the data, or was their agenda focused on generating evidence to assign blame?

Clearly, the most meaningful consumer data protection comes from taking responsible and prudent steps to prevent data loss. Even under the best of circumstances, no one can guarantee that a loss will never occur and that’s where California led the way in disclosure legislation.  In my opinion, this legislation was ill-conceived and I hope it won’t be back.

What do you think?

Schneier demonstrates poor airport security to The Atlantic [Roer.Com Information Security Blog - Information security for entrepreneurs]

Posted: 18 Oct 2008 12:35 AM CDT

I just love this story!

Not at all certain I would dare to try it myself. Reading how Schneier uses fake boarding passes, and brings 24oz of not identified liquid through the airport security is like reading a Ken Follet novel!

And you all know what I think of airport security!

IRS Computers Full of Security Holes [The IT Security Guy]

Posted: 17 Oct 2008 09:17 PM CDT

The IRS has sensitive data about 130 million people filing tax returns. But their computer systems storing that data have inadequate security controls, according to a study by the Treasury Inspector General for Tax Administration in a report released in September.

The security issues run the gamut from inadequate access controls, lack of auditing of privileged users and weak application security.

The study focused on the Customer Account Date Engine (CADE, for you acronym junkies who aren't US government employees), which is meant to streamline access to taxpayer data. I guess now that would also streamline access for hackers, as well.

The IRS was aware of the issues but didn't think they were important. Now, they do, and have agreed to work with the Inspector General's office to fix the vulnerabilities, the report says.

An interesting (to me) discovery... [PaulDotCom]

Posted: 17 Oct 2008 03:26 PM CDT

For you listeners of the podcast, you may be aware that I'm doing some research into utilizing document metadata, and the inferences that an attacker can make about the victims overall operating environment. This analysis would allow an attacker to be able to deliver more accurate, targeted attacks against a victim.

One of the tools that I've been using is Exiftool, which at it's core, is an over driven command line front end to all of the options of libexif.

The other day I discovered an advisory about a integer-overflow proceed_with_caution_2.jpgvulnerability in libexif, the basis to several other tools I've been looking at as well. There is no know vulnerability, but from the description, it seems fairly trivial to create a corrupt file to trigger the condition.

Time to proceed my analysis with more caution.

That said, you should always be analyzing unknown, untrusted files in a protected environment. Maybe the environment is an air-gapped machine, or a VM with no networking that you can revert to a known state. This, all in your non-production lab of course.

This also brings up some more points. I relate this to some of the updates to the tools that many of us use every day that introduce vulnerabilities into our environments. Don't forget that the complexity of the options in a tool (Wireshark for example), or the complexity and implementation if a standard (Exif, 802.11) all contribute to some potential downfall.

That said, I love multi-purpose, extensible tools and standards (Wireshark, Exif and 802.11 included!), but for these complexity reasons, it is important to keep them up to date, and evaluate the implementations.

Sometimes this is easier said than done.

- Larry "haxorthematrix" Pesce

Response: "Is Twitter the newest data security threat?" [HiR Information Report]

Posted: 17 Oct 2008 09:37 AM CDT

Lori MacVittie posted a compelling piece asking "Is Twitter the newest data security threat?"

In my opinion, the answer is "No." It's merely one of tens of thousands of potential avenues of exploitation that can be used intentionally or unintentionally by the real security threat: Those whom you trust to access your data in the first place.

Data Loss Prevention suites, Network Access Control, filtering web proxies and other technological solutions are only masking the problem while making it harder for your employees to work efficiently. Michael J. Santarcangelo, II's book, Into The Breach concisely discusses the real problem behind breaches and a sound Strategy to make it better. It takes everything we already acknowledge as security professionals and re-arranges it in a way that makes a lot of sense.

In short, security researchers, employers, and journalists need to wake up. Use technology to assist properly-trained employees who are held accountable for their mistakes instead of using technology to restrict clueless employees, and allowing the blame to fall on some software package when things go wrong. When do you start ACTUALLY trusting the people you trust with your data?

The issue of customer service via Twitter is a different bag of worms. The decision to use twitter as an enterprise avenue of support is a strategic decision that's better left to marketing, PR and CxO-types. I'd hope they'd analyze the potential impact of making a subset of their customer list public.

Playing / messing around with the template again [Roer.Com Information Security Blog - Information security for entrepreneurs]

Posted: 17 Oct 2008 08:46 AM CDT

I am reshaping the blog template again, and unlike what I preach, I do the testing directly on the production website.

When I where involved in website development and production back in the 1990s, I always had three copies of every site we managed - the production site, a full mirror of the production site for final testing and backup purpose, and a testing site for development. This enabled us to avoid what I am experiencing right now - where some simple and small changes changes the full look and feel of the website.

So my advice to you when you mess about with your blog, website, application or network - make sure you have a separate testing environment where you can make and test the changes before you apply them to the production system!

Learn by my mistakes!

Friday Geek-Out: WiFi Disruption Edition! [HiR Information Report]

Posted: 17 Oct 2008 08:38 AM CDT

If anyone still wants to go to Daily Dose tonight, that's fine. Some of us will be at Casa De Ax0n hacking on wireless stuff.

Given the fact that all things Karma have the potential to disrupt nearby WiFi service, we've opted to take the geek-out away from the normal venue this week. I really don't feel like getting banned from my favorite bar and coffee shop.

Like many others before me, I've freed my Fon from the wall outlet with a clip holding 4 AA batteries wired in series for 4.8 Volts. I'm currently using a 6-cell clip with the last two slots bypassed. It will hold five cells just fine for the full 6VDC that it was designed to use. I may do that this evening.

Asmodian X and I have been tinkering with these Fon routers for a few days now. We've both bricked (and subsequently un-bricked) them, and they're both running the latest version of OpenWrt.

Now it's time to see what we can do with them. The HiR WiFi Lab is going to be in full swing this evening. RSVP if you think you want to show up. I will need to clear it with w1fe 1.0, who probably doesn't want TOO many geeks coming over.

IDS: Vitamins Or Prophylactic? [Rational Survivability]

Posted: 17 Oct 2008 07:32 AM CDT

Agentmaxwell Ravi Char commented on Alan Shimel's blog titled "IDS - The Beast That Just Won't Die."

Ravi makes a number of interesting comments in his blog titled "IDS/IPS - is it Vitamins?"  I'd like to address them because they offer what I maintain is a disturbing perspective on the state and implementation of IDS today by referencing deployment models and technology baselines from about 2001 that don't reflect reality based on my personal experience.

Ravi doesn't allow comments for this blog, so I thought I'd respond here.

Firstly, I'm not what I would consider and IDS apologist, but I do see the value in being able to monitor and detect things of note as they traverse my network.  In order to "prevent" you first must be able to "detect" so the notion one can have one without the other doesn't sound very realistic to me.

Honestly, I'd like to understand what commercial stand-alone IDS-only solutions Ravi is referring to.  Most IDS functions are built into larger suites of IDP products and include technology such as correlation engines, vulnerability assessment, behavioral anomaly, etc., so calling out IDS as a failure when in reality it represents the basis of many products today is nonsensical.

If a customer were to deploy an IPS in-line or out-of-band in "IDS" mode and not turn on automated blocking or all of the detection or prevention capabilities, is it fair to simply generalize that an entire suite of solutions is useless because of how someone chooses to deploy it?

I've personally deployed Snort, Sourcefire (with RNA,) ISS, Dragon, TippingPoint, TopLayer and numerous other UTM and IDP toolsets and the detection, visibility, reporting, correlation, alerts, forensic and (gasp!) preventative capabilities these systems offered were in-line with my expectations for deploying them in the first place.

IDS can capture tons of intrusion events, there is so much of don't care events it is difficult to single out event such as zero day event in the midst of such noise. 

Yes, IDS can capture tons of events.  You'll notice I didn't say "intrusion events" because in order to quantify an event as an "intrusion," one would obviously have already defined it as such in the IDS, thus proving the efficacy of the product in the first place.  This statement is contradictory on face value.

The operator's decision to not appropriately "tune" the things he or she is interested in viewing or worse yet not investing in a product that allows one to do so is a "trouble between the headsets" issue and not a generic solution-space one.  Trust me when I tell you there are plenty of competent IDS/IPS systems available that make this sort of decision making palatable and easy.

To take a note from a friend of mine, the notion of "false positives" in IDS systems seems a little silly.  If you're notified that traffic has generated an alert based upon a rule/signature/trigger you defined as noteworthy, how is that a false positive?  The product has done just what you asked it to do!  Tuning IDS/IPS systems requires context and an understanding of what you're trying to protect, from where, from whom, and why.

People looking for self-regulating solutions are going to get exactly what they deserve.

Secondarily, if an attacker is actually using an exploit against a zero-day vulnerability, how would *any* system be able to detect it based on the very description of a zero-day?

It requires tremendous effort to sift through the log and derive meaningful actions out of the log entries.

I again remind the reader that manually sifting through "logs" and "log entries" is a rather outdated concept and sounds more like forensics and log analysis than it does network IDS, especially given today's solutions replete with dashboards, graphical visualization tools, etc.

IDS needs a dedicated administrator to manage. An administrator who won't get bored of looking at all the packets and patterns, a truly boring job for a security engineer. Probably this job would interest a geekier person and geeks tend to their own interesting research!

I suppose that this sort of activity is not for everyone, but again, this isn't Intrusion Detection, Shadow Style (which I took at SANS 1999 with Northcutt) where we're reading through TCPDUMP traces line by line...

There are companies that do without IDS, and they do just fine. I agree with Alan's assessment that IDS is like a Checkbox in most cases.  Business can run without IDS just fine, why invest in such a technology?

I am convinced that there are many companies that "do without IDS."  By that token, there are many companies that can do without firewalls, IPS, UTM, AV, DLP, NAC, etc., until the day they realize they can't or realize that to be even minimally compliant with any sort of regulation and/or "best practice" (a concept I don't personally care for,) they cannot.

I'm really, really interested in understanding how it is that these companies " just fine."  Against what baseline and using what metrics does Ravi establish this claim.  If they don't have IDS and don't detect potential "intrusions," then how exactly can it be determined that they are better off (or just as good) without IDS?

Firewalls and other devices have built in features of IDS, so why invest in a separate product.

So I misunderstood the point here?  It's not that IDS is useless, it's just that standalone IDS deployments from 2001 are useless but if they're "good enough" functions bundled with firewalls or "other devices," they have some worth because it costs less?

I can't figure out whether the chief complaint here is an efficacy or ill-fated ROI exercise.

IDS is like Vitamins, nice to have, not having won't kill you in most cases. Customers are willing to pay for Pain Killers because they have to address their pain right away. For Vitamins, they can wait. Stop and think for moment, without Anti-virus product, businesses can't run for few days. But, without IDS, most businesses can run just fine and I base it out of my own experience.

...and it's interesting to note the difference between chronic and acute pain.  In many cases, customers don't notice chronic pain -- it's always there and they adjust their tolerance thresholds accordingly.  It may not kill you suddenly, but over time the same might not be true.  If you don't ingest vitamins in some form, you will die.

When an acute pain strikes, people obviously notice and seek immediate amelioration, but the pain killer option is really just a stop-gap, it doesn't "cure" it simply masks the pain. 

By this definition it's already too late for "prevention" because the illness has already set in and detection is self-evident -- you're ill.  Take your vitamins, however, and perhaps you won't get sick in the first place...

The investment strategy in IDS is different than that of AV.  You're addressing different problems, so comparing them equliaterally is both unfair and confusing.  In the long term, if you don't know what "normal" looks like -- a metric or trending you can certainly gain from IDS/IPS/IDP systems -- how will you determine what "abnormal" looks like?

So, sure, just like the vitamin example -- not having IDS may not "kill" you in the short term, but it can certainly grind you down over the long haul.

Probably, I would have offended folks from the IDS camp. I have a good friend who is a founder of an IDS company, I am sure he will react differently if he reads my narratives about IDS.  Once businesses start realizing that IDS is a Checkbox, they will scale down their investments in this area. In the current economic climate, financial institutions are not doing well. Financial institutions are big customers in terms of security products, with the current scenario of financial meltdown, they would scale down heavily on their spending on Vitamins.

Again, if you're suggesting that stand-alone IDS systems are not a smart investment and that the functionality will commoditize into larger suites over time but the FUNCTION is useful an necessary, then we agree.

If you're suggesting that IDS is simply not worthwhile, then we're in violent disagreement.

Running IDS software on VMware sounds fancy.  Technology does not matter unless you can address real world pain and prove the utilitarian value of such a technology. I am really surprised that IDS continues to exist. Proof of existence does not forebode great future. Running IDS on VMware does not make it any more utilitarian. I see a bleak future for IDS.

Running IDS in a virtual machine (whether it's on top of Xen, VMware or Hyper-V) isn't all that "fancy" but the need for visibility into virtual environments is great when the virtual networking obfuscates what can be seen from tradiational network and host-based IDS/IPS systems. 

You see a bleak future for IDS?  I see just as many opportunites for the benefits it offers -- it will just be packaged differently as it evolves -- just like it has over the last 5+ years.


Application logging - How it's not supposed to be [Roer.Com Information Security Blog - Information security for entrepreneurs]

Posted: 17 Oct 2008 07:26 AM CDT

Anton is on a plane to California. Thanks to modern technology - scheduled posting - he just posted his take on how not doing application logging.

If you are into software development, you might find his insights to very useful.

Autumn 2008 Edition of 2600 on Newstands [The IT Security Guy]

Posted: 16 Oct 2008 09:34 PM CDT

It seemed a bit early, but I happened to see the latest issue of 2600 on the newstand this week, and snapped it up, as I do every three months.

As always, there's some good stuff in here. There are articles about Tor, cyberwar, Google Analytics, Blackhat SEO, pen testing and USB forensics.

Will You All Please Shut-Up About Securing THE Cloud...NO SUCH THING... [Rational Survivability]

Posted: 16 Oct 2008 04:24 PM CDT

Cloudy-finger How'd ya like this picture of "THE Cloud..."

This love affair with abusing the amorphous thing called "THE Cloud" is rapidly  approaching meteoric levels of asininity.  In an absolute fit of angst I make the following comments:

  1. There is no singularity that can be described as "THE Cloud."  There are many clouds, they're not federated, they don't natively interoperate at the application layer and they're all mostly proprietary in their platform and operation.  They're also not all "public" and most don't exchange data in any form. The notion that we're all running out to put our content and apps in some common repository on someone else's infrastructure (or will) is bullshit.  Can we stop selling this lemon already?

    Yay!  More people have realized that outsourcing operations and reducing both OpEx and CapEx by using shared infrastructure makes sense.  They also seem to have just discovered it has some real thorny issues, too.  Welcome to the 90's. Bully!

    Just like there are many types of real billowing humid masses (cumulonimbus, fibratus, undulatus, etc.) there are many instantiations of resource-based computing models that float about in use today --,, Clean Pipes from ISP's, Google/Google Apps, Amazon EC2, WebEx -- all "cloud" services.  The only thing they have in common is they speak a dialect called IP...
  2. The current fad of butchering the term "Cloud Computing" to bring sexy back to the *aaS (anything as a service) model is embarrassing.  More embarrassing is the fact that I agree with Larry Ellison wherein he stated:

    "The interesting thing about cloud computing is that we've redefined cloud computing to include everything that we already do. I can't think of anything that isn't cloud computing with all of these announcements. The computer industry is the only industry that is more fashion-driven than women's fashion. Maybe I'm an idiot, but I have no idea what anyone is talking about. What is it? It's complete gibberish. It's insane. When is this idiocy going to stop?"

  3. It ain't new, folks. Suggesting that this is a never-before-seen paradigm that we've not faced prior and requires "new" thinking as to privacy, trust models, security as a service layer and service levels mocks the fact that the *aaS model is something we've been grappling with for years and haven't answered.  See #2.  I mean really.  I've personally been directly involved with cloud-models since the early 90's.  Besides the fact that it's become (again) an economically attractive and technologically viable option doesn't make it new, it makes it convenient and marketable.
  4. Infrastructure Gorillas are clouding the issue by suggesting thier technology represents THE virtual datacenter OS.  Microsoft, Citrix, VMware, Cisco.  They all say the same thing using different words.  Each of them claiming ownership as the platform/OS upon which "THE cloud" will operate.  Not one of them have a consistent model of securing their own vDCOS, so don't start on how we're going to secure "IT."

    (Ed: In fairness just so nobody feels left out, I should also add that the IaaS (Infrastructure as a service)/integrator gorillas such as IBM and HP are also in the mix -- each with their own flavor of service differentiation sprinkled on top.)

If you thought virtualization and its attendant buzzwords, issues and spin were egregious, this billowy mass of marketing hysteria is enough to make ;)

C'mon, people. Don't give into the generalist hype.  Cloud computing is real.  "THE Cloud?"  Not so much.


(I don't know what it was about this article that just set this little rant off, but well done Mr. Moyle)

Insiders dodge security for productivity, RSA says [Telecom,Security & P2P]

Posted: 16 Oct 2008 09:44 AM CDT

In a recent survey by RSA, a fact was discovered that insiders dodge security for productivity. I agree that it’s very common at a company that workers and employees share a computer or share some accounts. It might be a not-bad compromise for a non-critical and non-sensitive IT environment in order to cost saving. Anyway, in most cases, it violate best practice and should be corrected.

[Chinese]clickjacking攻击 [Telecom,Security & P2P]

Posted: 16 Oct 2008 09:16 AM CDT

SecurityFocus报道了一种新型的基于web的攻击方式 - clickjacking。简单说是一种通过web显示与用户实际看到的内容不一致的浏览器缺陷,来引导用户点击或者输入攻击者想要的动作或内容。像按钮、图像、表单、链接等都可能被用来实施这种攻击。通过巧妙地设计,攻击者可以通过点击劫持,可以操控被害者的摄像头和麦克风。并且根据报道,当前的集中主流的浏览器,像IE, Chrome, Safari, Opera等都不能幸免。而当前Firefox3.0上的一个插件 - NoScript可以帮助保护避免这种攻击。

发明者Hansen and Grossman给这种攻击方式取了这个名字Clickjacking - 点击劫持,也很形象,一种欺骗性的hijacking。它比简单的基于域名欺骗的网络钓鱼更有隐蔽性和欺骗性。


简单的说Clickjacking是一种攻击,是一种新型的WEB方式攻击。上面所涉及到的"Flash Player漏洞",其实只是Clickjacking安全漏洞一种表现形式。

Clickjacking翻译可以将他拆成click-jacking来理解,click是点击的意思(鼠标点击),jacking应该是劫持的意思(hijacking的缩写?不得而知)。联起来翻译就是"点击劫持"。这里也涉及到了Clickjacking的说法,他们把"Clickjacking"叫做"UI redress vulnerabilities(界面伪装漏洞 )",这个解释也许更能描述清楚这个漏洞的情况。


在 你可控制的页面A内有一个iframe,iframe的src链接到另一个域的页面B。设置这个iframe的CSS样式的透明度为0,并设置其 CSS样式的z-index比页面A的其他元素的z-index大。这个iframe的width与height值都设置为足以保证用户可以点击到其中内 容(页面B的内容)的大小。然后在页面A上放置一些按钮、链接等可以欺骗用户点击的元素,这些元素在iframe之下(z-index值决定),并恰好与 iframe的页面B内的关键元素在同一个位置。于是当用户被欺骗去点击页面A内的这些元素时,实际上点击了页面B内的关键元素。至于页面B内的关键元素 是什么,大家想想便知,比如:删除按钮、添加按钮、单选框、请求链接等等。再加上一些社工技巧,这类攻击方式可以进行得非常巧妙。这种攻击基于DHTML 技术,用到了iframe,而且这样的攻击方式不一定需要JS。



Job Opportunity of Server Architect [Telecom,Security & P2P]

Posted: 16 Oct 2008 01:50 AM CDT

There is a good job opportunity in our organization. If you are interested or have friends to recommend, please don’t hasitate to contact me by sending the CV/resume to my email address (richard.zhaol at gmail dot com)

Job Discription:

This is a senior technical position of Global Infrastructure Department, under CIO organizations. This is an individual contributor, direct report to Director of Architect and Security Operations.

1. Lead the global roadmap and technology innovations related to server, storage, virtualization.
2. Lead the design the overall architecture and standards for global server and storage
3. Communicate with global business users and collect, analyze their requirements
4. Design the solution to meet the business requirements, with support from SME (subject matter expert) from operation towers
5. Lead the design and define of technical manuals and templates used for operational enhancements and changes.


1. Bachelor  degree majored in Computer Sciences or Electrical Engineering with very good academic performances (Master/PhD a plus)
2. Minimum 10 Years working experience as IT Operation/Consulting engineer/architect, minimum 5 years IT system design experience, minimum 3 years large scale server and storage system design experience
3. Strong technical background in related fields, ie. networking, telecom and security technologies (Experience at ITIL is a plus)
4. Good communication skill. Good written/spoken English, be able to give technical talks/presentation both in English.

Links for 2008-10-15 [] [HiR Information Report]

Posted: 16 Oct 2008 12:00 AM CDT

Links for 2008-10-15 [] [Sicurezza Informatica Made in Italy]

Posted: 16 Oct 2008 12:00 AM CDT

ROSI : Quando conviene investire in sicurezza informatica [Sicurezza Informatica Made in Italy]

Posted: 15 Oct 2008 05:36 PM CDT

Dopo un bel po di assenza causa lavoro e progetti vari torniamo all'argomento investimenti in ambito di sicurezza informatica.

Nel post precedente ho cercato di fornire un idea sugli step da seguire prima di arrivare a delineare un budget di spesa per la sicurezza informatica. Un consulente di sicurezza informatica può aiutare a definire gli obiettivi e le priorità da perseguire per non vanificare l'efficacia dei budget di spesa, che coi tempi che corrono sono sempre più ristretti.

In questo post vorrei dare il mio contributo alla discussione sul ROI e ROSI in ambito sicurezza e chiarire molti dei "misbelief" che purtroppo dominano il settore.

La prima domanda da porsi è: ha senso parlare di ROI per la sicurezza?
Se si vuole essere economisti puri, certamente no. Il ROI presuppone un Return, ricavo dall'investimento, che chiaramente non esiste per spese in favore di maggiore sicurezza e protezione.

Per chiarire ogni dubbio:
Mentre in generale il ROI presuppone un guadagno a fronte di una costo, il ROSI presuppone un risparmio a fronte di un costo.

Si affronta un investimento in sicurezza (costo) per evitare una perdita risultante da un attacco con successo agli asset aziendali. Cost avoidance. Il ROSI è positivo quando il costo è minore della perdita.

Questo stravolgimento di concetti è ciò che ha confuso molti addetti del settore e scoraggiato molti manager ancorati ai dogmi dell'economia pre-informatica.

Fin qui sembrerebbe solo un problema di cambio di mentalità per cui come nell'evoluzione della specie, chi sa adattarsi ai cambiamenti sopravvive, gli altri soccombono.

Non è così semplice purtroppo. Prima di capire perché, bisogna avere davanti agli occhi le formule coinvolte nel calcolo del ROSI:

Per singolo rischio

SLE= Single Loss Expectancy (Perdita per singolo rischio)
AV = Asset value (valore economico dell'asset da proteggere)
EF = Exposure Factor (probabilità che il rischio diventi reale)

L'investimento è il costo da sostenere per ridurre di un certo livello percentuale l'EF
connesso al rischio considerato.
Questo include la supposizione, corretta a mio parere, che nessuna spesa in termini di sicurezza
può veramente ridurre a 0 l'EF, cioè la probabilità che l'attacco si realizzi con successo.

L'investimento in sicurezza è volto a diminuire il più possibile il SLE diminuendo l'EF.

Un esempio pratico chiarisce il concetto:

Una risorsa (asset) il cui valore ammonta a 1Mln di euro, ha una probabilità di essere compromessa pari al 10% (EF).

L'ammontare a rischio, in termini monetari, è pari a 100,000 euro.
(Il 10% di 1Mln di euro).

Spendendo 50,000 euro per far scendere l'EF al 2%, avremmo in questo caso solo 20,000 euro a rischio risparmiando 80,000 euro a fronte di un investimento di 50,000 euro.
Il ROSI a questo punto è del 160% e il nostro investimento di 50,000 ha fatto scendere l'EF da 10% a 2% riducendo lo SLE.

Come si può notare dalla precedente formula i problemi del calcolo del ROSI sono molteplici:
  • Il calcolo si basa sulle probabilità che un evento accada
  • Non ci sono statistiche approfondite e affidabili sulla frequenza degli eventi e l'incidenza delle minacce
  • I costi post-disaster sono in parte deterministici e in parte aleatori (deterministici per quanto riguarda il valore dell'asset da proteggere, aleatori per quanto riguarda danni d'immagine, sanzioni connesse).

Nel precedente esempio, lo SLE include costi che fanno capo alle seguenti voci:

  • danni economici (es. business continuity)
  • sanzioni per inadempimento alle compliance/regulations (si pensi ala PCI compliance o a eventi di data breach che causano apertura di fascicoli da parte delle autorità di vigilanza per la protezione della privacy)
  • danni di immagine
  • perdita del segreto industriale (costo sostenuto per il raggiungimento degli obiettivi di progetto a vantaggio dei concorrenti)
  • altri a seconda della natura e dimensione dell'organizzazione

Alla luce delle precedenti osservazioni ha ancora senso parlare di ROSI?
Il ROSI non compare mai in documenti finanziari ma può essere utile per decidere la fattibilità e la convenienza dell'investimento in sicurezza qualunque sia la dimensione dell'organizzazione.

Chi assegna i valori nella formula dello SLE?

A dare un valore alla variabile AV è solitamente il livello esecutivo che meglio di ogni altro conosce il valore economico di ogni asset aziendale.

Una corretta gestione della variabile EF è compito esclusivo di un esperto di sicurezza che deve essere a conoscenza dello stato della sicurezza pre-investimento e deve essere in grado di valutare il livello di incidenza di ogni minaccia.

Nei prossimi post voglio espandere il concetto di ROI applicato all sicurezza informatica.
Non è vero che non si può guadagnare da un investimento in sicurezza. Alla prossima

[Chinese]俄国研究人员破解WPA2提速100倍 [Telecom,Security & P2P]

Posted: 15 Oct 2008 09:24 AM CDT

俄国公司ElcomSoft Co. Ltd研究成功使用nVidia视频卡GPU破解WPA/WPA2提速100倍。这个报道引起了很多安全人士的兴趣。



No comments: