There is another reason why the article got my attention; my manager, Steve Lipner, is one of the few people to have designed and built a TCSEC A1 assured system and lived to tell the tale. None were sold, but they built one!

The NSA-directed project, the Tokeneer ID Station (TIS), involved building a low-defect system that conforms "to the Common Criteria requirements for Evaluation Assurance Level 5 (EAL5)" in a "cost effective manner." I'm all for this, because building high-assurance solutions is not cheap.

There's a paper with more technical detail about the project that is worth a read.

In my opinion, the project is only a science project, an experiment, for the following reasons:

• It's tiny. Weighing in at a little under 10 KLOC.
• It's only a very small portion of a much larger solution which has not been developed using the same rigor. This bit of context makes the solution as a whole moot. Call me cynical, but my question is "can the entire solution be built with same rigor in a ‘cost effective manner'?" Perhaps it can, but that is not what is presented.
• It sits on top of many operating systems (Windows, Mac OS X and Linux) that are not EAL5 certified. So it would be a little like having an EAL5 certified CharMap application running on EAL4 Windows Vista.
• It's written in a subset of Ada called SPARK, and SPARK skills are not common in the marketplace. Interestingly, SPARK makes use of annotations to help drive the static analysis process. While not a total analog, we also recommend Microsoft development teams use annotations (SAL) to help drive the required static analysis process.
• The application has a large number of dependencies that are not part of the project:

In the SDL we call these files ‘giblets' because they are components needed for your application to operate, but they do not belong to your team. Some of the files look old and highly vulnerable, such as libpng-3.dll from 2001! OSVDB lists 23 vulnerabilities since 2002 in libpng!

In summary, the TIS project is very interesting to a small number of important but specialized customers, such as the NSA, for whom this kind of research is critical. I too found it interesting, but the process is far from a set of "secrets to writing secure code" and the tools are certainly not within reach of day-to-day applications and not applicable to developing complete solutions.

Setting the Web Application Security Agenda for 2009: OWASP Invites You to Join Our Summit in Portugal

http://www.owasp.org/index.php/OWASP_EU_Summit_2008

With the theme ‘Setting the AppSec agenda for 2009′, the OWASP Summit will be a worldwide gathering of OWASP leaders and key industry players to present and discuss the latest OWASP tools, documentation projects, and web application security trends. Join us in Portugal in just a few short weeks! This venue hosts a diverse selection of training courses along with technical and business tracks, making it THE place to learn about web application security and the resources OWASP has available for use today.

OWASP is a not-for-profit organization with the purpose of supporting the Web Application Security community around the world, and has granted $250,000 USD for web application security research. In addition to over 40 presentations from the OWASP Leaders and grant recipients, the OWASP Summit will host multiple Working Sessions designed to improve collaboration, achieve specific objectives and identify roadmaps for OWASP projects, chapters, and the OWASP community itself.

To facilitate this event, OWASP is investing $150,000 USD which will be used to cover air travel and accommodation expenses for OWASP leaders, active contributors, and select key industry leaders. With their confirmed presence, the OWASP Summit will provide a relaxed but professional environment to meet, discuss, influence and contribute to OWASP projects.

There are still funds available! If you are interested in attending and you meet the profile of the current OWASP supported attendees (see list here: http://spreadsheets.google.com/pub?key=pAX6n7m2zaTVLrPtR07riBA) contact Paulo Coimbra (paulo.coimbra@owasp.org). Please note that you should do so only if you meet the paid attendance criteria (see herehttps://www.owasp.org/index.php/OWASP_EU_Summit_2008_paid_participation_rules) and are unable to get corporate support to attend this event (for other corporate sponsorship opportunities see http://www.owasp.org/index.php/OWASP_EU_Summit_2008_Sponsors).

The OWASP Summit will also host a large and diverse selection of training courses, covering multiple OWASP specific and Web Application Security Topics.

The remarkable impact of OWASP is made possible only by the collaboration of many dedicated people and organizations worldwide. In that spirit of cooperation, OWASP invites all its members (who have 20% discount + 1 VIP Ticket) and interested individuals and companies to attend this thrilling event. Please join us and help to set the Web Application Security Agenda for 2009!

Please see below for additional details about the OWASP Summit or visit the OWASP Summit website: http://www.owasp.org/index.php/OWASP_EU_Summit_2008.

Projects

OWASP projects selected for Summit presentation include new documentation and innovative tools to help developers, architects, and security specialists ensure that applications are secure:

• Application Security Verification Standard,
• Code review guide, V1.1,
• Ruby on Rails Security Guide v2,
• Securing WebGoat using ModSecurity,
• Testing Guide v3,
• GTK+ GUI for w3af project,
• Access Control Rules Tester,
• AntiSamy .NET,
• Live CD & DVD Project,
• OpenPGP Extensions for HTTP,
• Orizon Project,
• Python Static Analysis,
• WebScarab-NG,
• And many, many others.

Working Sessions

Expecting the presence of the application security industry key players, the Working Sessions will cover a wide range of issues such as:

• OWASP Top 10 2009,
• Browser Security,
• Web Application Framework Security,
• Enterprise Security API Project,
• Best Practices for OWASP Chapter Leaders,
• OWASP Documentation Projects,
• OWASP Tools Projects,
• OWASP Education Project,
• OWASP Strategic Planning for 2009,
• OWASP Certification,
• OWASP Winter of Code 2009
• Two-way Internationalization of OWASP Content
• And many more.

Training

These 2-day, 1-day or 1/2-day training courses cover a wide range of OWASP specific and Web Application Security Topics:

• OWASP Top 10 - What Developers Should Know on Web Application Security
• Uncovering WebScarab’s Secret Treasures
• Securing WebGoat with ModSecurity
• Secure Programming with Java
• Advanced Web Application Security Testing
• Building Secure Web 2.0 Applications
• Building Secure Web Services
• Building Secure Web Applications with OWASP’s Enterprise Security API (ESAPI)
• Classic ASP Security using OWASP tools
• Web Application Assessments
• Hacking Owasp Orizon Project v1.0
• Ajax Security
• Practical Penetration Testing: Think Like an Attacker to Stop Attacks
• Linux Software Exploitation
• Web server/services hardening using SELinux

Main Contact:

Kate Hartmann
OWASP Operations Director
9175 Guilford Road, Suite 300
Columbia, MD 21046, USA
Phone: +1-301-575-0189
Facsimile: +1-301-604-8033
Email: kate.hartmann@owasp.org

I’m assuming the author wants us to read the title as “Things to Look Out For in Performing Risk Analysis” and not “Risk Management is Folly - Stop, Stop, Stop!” The former is fine, the latter isn’t supported by the evidence presented by the subjects of the article.
The subjects of the article are a good study from Wade Baker & Co. at Verizon, and a report from RSA’s Security for Business Innovation Council. Let’s take a look at each of these and examine why what they’re saying might contribute to poor risk management, shall we?

1.)  THE VERIZON REPORT

The Verizon report is an analysis of some 530 forensic investigations their company performed.  It is well worth your time as it’s chock full of interesting information.  As it relates to the Dark Reading piece, a coarse summary would be that “likelihood” is “different” for different people and so you can’t use the same “likelihood” across different industries.

Distilled through the lens of FAIR:

“different threat communities may be applicable based on Probability of Action factors which include: Value, Level of Effort and Risk (of Getting Caught).”

Or, even further distilled and in the words of my six year old son,

“Duh-uh”.

With regards to what I assume is the purpose of the article (What Doesn’t Work in Risk Analysis) this concept  seems just to rehash the old GIGO argument regarding risk analysis.  Great.  Can’t argue with that, nor it’s corollary QIQO (quality in, quality out).

But let me ask you -  is this really a problem common in your analysis?  Did reading this article make you go “Crap, we’ve been using data normalized across multiple industries in our analysis! They’re all wrong!”  Or have you already been accounting for the unique value proposition your company has to the specific threat community you’re worried about?  See, maybe I’m just not your average analyst, but even in my NIST/OCTAVE days, this has *never* been an issue for me.

Let me be specific, this is not a problem with Verizon’s very cool report.  It’s just that I don’t see what the big deal is.  This article is starting to feel like someone is running through the motions, trying to play the ” a crazy title gets people to read a boring article” game.

Speaking of cool reports - You know what would be cool?  I think it would be interesting to see is the quality of these companies’ “risk management process” established using good criteria,  and then correlated to the frequency and magnitude of real-world losses across the aggregate sample.  In other words, can we establish evidence that strong risk management practices not just reduce “risk” but also reduce actual incidents.

2.)  THE RSA COUNCIL “EXPLORES WHY LEGACY METHODS OF EVALUATING INFORMATION SECURITY RISK DON’T WORK IN TODAY’S CONNECTED WORLD, IN WHICH ANY NEW BUSINESS INNOVATION INHERENTLY CARRIES SOME LEVEL OF RISK TO INFORMATION.”

This report from the RSA council puts forth a seemingly obvious proposition, that risk must be balanced by reward.  Why is this news?  Now as I read the article it’s not clear if:

• The RSA Council is claiming that the CISO’s office should be the ones determining reward.  Absurd.

or

• Businesses aren’t doing a good job at determining risk and reward.

Let’s go with the latter.  So I’m pretty sure (good) businesses do a good job at estimating reward.  Businesses I’ve been a part of?  We LOVE(D) estimating reward.  We don’t tend to start projects all willy-nilly. No we tend to be careful to identify the size of the market and what it will cost to address the market.  So what could the problem be that this RSA council is trying to address?  Maybe it has to do with something like the following:

Yesterday, I got a demo of an IT-GRC application that shall remain nameless.  It seemed to be very good at the “C” bits - lots of information on regulations and expectations and even what sorts of controls would answer the regulations (which is goofy, but we’ll have to talk about that later).  It also gave you the ability to build workflow quite nicely.  But it measured NOTHING.  There really was no observable “G” and “R” was really Medium X Low X Low = High sorts of stuff.  So let’s use this relatively expensive tool as evidence of what your average CISO is armed with going into a Risk/Reward sort of meeting.  I imagine a nice board room with wood-grain paneling and glass bowls filled with little chocolate covered mints designed to give everyone involved in the meeting (CEO, CFO, CIO, CSO, VP S&M, etc…) a little sugar rush when needed and fresh breath.  The conversation goes a little something like this (apologies to Rich):

Business Guy Who Wants to Make Money Because That’s What Businesses Do: Based on market studies, we believe that initial gross revenues from the new product and technology rollout will be eleventy gazillion dollars based on a 37% market penetration in Scandinavia, alone.

CSO: Well now, we have a likelihood of “High” and a “C” impact of Medium, and an “I” impact of Low, and an “A” impact of “High” and because we are a (bank/hospital/retailer/basically any business that breathes anymore) we weight “C” by a factor of 2 - we multiplied those all together and got a “High”.

So can you guys delay the product rollout by 9 months and give me a bunch more money that’s not in the budget so that I can get this thing down to a “Medium”, please?

Again, I just don’t see the problem with Information Risk Management being that our businesses have no idea what the rewards of business might be.  Now maybe we need get a seat in that boardroom just to be able to talk about our “Mediums”, sure.  And maybe we’re infantile in our ability to describe our problem space.  But I cannot fathom that “Risk Management Doesn’t Work” because businesses haven’t been considering “reward”.

WHY RISK MANAGEMENT MAY  NOT BE WORKIN’ FOR YOU

Two meta-categories of causation:

• No skills

and/or

• No resources

Any ancillary “cause” can be mapped to one of these categories.  You could have significant resources but crappy models, and have conversations like our imaginary CSO, above.  You could have really good models and people trained and motivated to use them, but scarce time & money, so no conversation happens.

Now my question for you is - which does it make sense to acquire *first* to solve the “Why Risk Management Doesn’t Work” problems, skills or resources?

The announcement is of course Good News — because once the PCeU is up and running next Spring, it should plug (to the limited extent that £2 million a year can plug) the “level 2″ eCrime gap that I’ve written about before. viz: that SOCA tackles “serious and organised crime” (level 3), your local police force tackles local villains (level 1), but if criminals operate outside their force’s area — and on the Internet this is more likely than not — yet they don’t meet SOCA’s threshold, then who is there to deal with them?

In particular, the PCeU is envisaged to be the unit that deals with the intelligence packages coming from the City of London Fraud Squad’s new online Fraud Reporting website (once intended to launch in November 2008, now scheduled for Summer 2009).

Of course everyone expects the website to generate more reports of eCrime than could ever be dealt with (even with much more money), so the effectiveness of the PCeU in dealing with eCriminality will depend upon their prioritisation criteria, and how carefully they select the cases they tackle.

Nevertheless, although the news this week shows that the Home Office have finally understood the need to fund more ePolicing, I don’t think that they are thinking about the problem in a sufficiently global context.

A little history lesson might be in order to explain why.

Back in 1930’s, Bonnie and Clyde and other US bank robbers were using the new-fangled automobile to flee across state lines — creating jurisdictional problems as a result. The US solution was to make bank robbery (along with auto-theft and other related offences) into federal offences rather keeping them as state-specific infractions. In particular this meant that the FBI could provide federal level policing (tracking down and killing John Dillinger for example).

We have the same jurisdictional issues dealing with cyberspace, with criminals in one country fleecing consumers in another while using systems hosted in a third. The Convention on Cybercrime addresses part of the problem by trying to ensure international consistency where eLaws are specifically needed (which of course is only the case for small parts of eCriminality, fraud is fraud whether eEnabled or not). However, there is limited inter-jurisdictional co-ordination for eCrime investigations — for example Interpol (often incorrectly perceived to be international police force) merely keeps a large database and passes faxes from one place to another.

In practice, most cross-border investigations are done as “joint operations” and the jointness is usually very limited — one force does all the legwork and a liaison officer in the other country deals with local paperwork. There’s usually a quid pro quo element to these joint operations, for budgeting reasons if no other.

What isn’t happening, or at least only in a handful of very specialised areas, is any international co-operation in setting priorities or selecting cases to pursue. Every country is doing its own thing about eCrime, and there’s a widespread impression that any criminal who can operate from “across the state line” is essentially immune from serious investigation.

We identified this problem last year when we (Ross Anderson, Rainer Böhme, Tyler Moore and myself) wrote a report on Security Economics and the Internal Market for ENISA. It’s not an easy one to fix whilst politicians (and populaces) are unwilling to see “foreign” police officers operating in their country, and the establishment of a truly international “cyber police force” seems equally unlikely.

Our policy proposal to tackle the issue harks back to WWII’s SHAEF, which has morphed into similar arrangements within NATO. In essence liaison officers from multiple forces would sit around a single table, working with a central coordinator, to set policy and decide which investigations to pursue. They would then communicate back to their own countries, who have specifically budgeted to provide appropriate assistance. So it’s very like “joint operations”, but the scheme is multi-laterial, and has a true command and control function in the centre — who will quickly learn to shy away from politically sensitive topics and make a real impact on eCriminality.

To summarise then, a welcome to the Home Office for finally finding a small amount of funding for some country-wide ePolicing; but it’s well past time to be working on world-wide initiatives.

So, what are we hoping to gain by creating a network of security consulting and training experts to work with customers who want to implement the SDL?  Generally speaking, this question has a two-part answer:  First, Microsoft is, and always will be a partner-driven company - we rely on the skills and capabilities of our partners to provide specialized services and broad geographic coverage for Microsoft products and services.  Second, even though there are talented folks in the Microsoft Services organization, it's clear that we will need help from our partners to scale to meet the demand.  I can't tell you how many times the folks on the SDL team have been approached by people - after an executive briefing, or a session at TechEd - asking for guidance in implementing SDL in their own organizations.  When we look at the demand and pair it with the geographic diversity of our customer base, it's clear that a partner approach is the right answer.

Now a few words about the partners who will be participating in the pilot phase...

After the decision was made to work with partners on SDL delivery, we had two primary criteria that we had to address; partner quality, and manageability of the SDL Pro Network pilot. We have all seen instances where individuals or consulting organizations have represented themselves to the IT community as having security expertise when in reality the "experts for hire" were simply reading a page or two ahead of the customer in whatever security tome was "in vogue" at the time. 

Based on those observations, it was clear that partner "quality" was a critical criterion.  Fortunately for us, we didn't have to look far to satisfy our quality bar - many of the companies in the SDL Pro Network pilot have direct experience with executing portions of the SDL on our products, or have delivered services to Microsoft in a security context. Design reviews, code reviews, penetration testing, training and other tasks critical to SDL implementation were (and are) common fare for these folks.

Despite the customer demand for SDL that I alluded to above, starting with a small pilot was the right thing to do; a small group of trusted consultancies supports our imperative for quality and it allows us to pragmatically grow the SDL Pro Network as the market matures.  As we continue to evolve and innovate with the SDL, we'll have a strong core of partners to help drive the software security message.

Will we grow the SDL Pro Network?  The qualified answer is: "When the market demands it..." - there are a number of talented potential partners who meet the quality bar - and clearly, the need for security in software development will grow to demand additional talented specialists. However, it's our plan to begin with a small set of partners of known expertise, and then respond to growing demand as it materializes.

So there you have it - the nuanced beginning and bright future of the SDL Pro Network...  I invite your comments, and encourage you to check in at the SDL Portal as we continue to build out the program

The following excellent discussion is reposted from Streaming SQL approaches insist in ignoring causality by PatternStorm.

The recent paper “Towards a Streaming SQL Standard” by Oracle and Streambase unifies and generalizes two different execution models of Streaming SQL: Oracle’s and StreamBase’s.

While it’s true that the generalization succeeds in overcoming the unability of both execution models of producing correct results for astonishing simple queries (showing evidence of the actual limitations of these two Streaming SQL languages) it is also true that the generalization is closer to being overly complex than natural and intuitive.

The root cause behind the actual limitations of these two Streaming SQL languages is that their execution models “hardcode” the way events can be related to each other: in the Oracle case events are partially ordered by timestamp, in the StreamBase case events are totally ordered by time of arrival. These design decisions (natural in a stream oriented lamguage) have strong implications on what queries can be answered correctly, particularly when these queries involve joins of derived streams.

The generalization, of course, mainly consists in providing a new operator that allows the user to establish custom ordering relationships among the events (the SPREAD operator), which is good news but takes us to the fundamental issue: event processing cannot be reduced to stream processing, that is, to the processing of events that are totally or partially ordered by a pre-defined relationship (as Oracle and StreamBase actual implementations do), on the contrary, no particular ordering can be assumed because the user needs to be able to order the events in different ways in order to solve different problems. This is what event processing is about and the paper provides evidence that Streaming SQL approaches have found the need to move towards that direction and are having trouble in their way.

For instance, one of the queries used in the paper as an example of a query that StreamBase cannot solve (but Oracle can) is the following: correlate the stream that contains the total number of cars on the road for each time interval with the stream that contains the total average speed of the cars on the road for each time interval in order to detect the situation where the avergae speed is below 45 and the total number of cars is two or more. This query can be very easily and more robustly solved if you order the events by causality rather than by time, that is, if you have each position report update the average speed stream and the total number of cars stream and then you causally relate each position report to the new average speed event and the new total number of cars event that it generates; then the query is just a matter of detecting all report speeds that are causally related both to an average speed event below 45 and a total number of cars event of two or more (notice that this approach is more robust than Oracle’s time-based one because it works without requiring derived streams to be synchronized with the report speed stream)

Conclusions:

• Event Processing is a generalization of Stream Processing (as the paper shows)
• Event Processing requires providing the ability to the user of creating custom relationships among events and then define patterns/queries using those custom relationships.
• Causality is more often than not a more robust and easier criteria to order events than time or order of arrival.
• Event Processing Languages should support causality.

Regards,
PatternStorm

Blogger: Randall Gamby

Two weeks ago the PCI Security Standards Council released the preliminary details of the PCI Data Security Standard (DSS) V1.2 that’s due out in October.  While many Analysts and Reporters have already written on the topic (I’ll be releasing an extensive update on Burton Group’s PCI coverage around the October release date), they really haven’t commented on what’s still not been addressed by the standard for enterprises still working on attaining compliance.

While I applaud the PCI Security Standards Council in further clarifying and adjusting the standard, a lot of work still needs to be done.  I receive about one or two PCI questions a week from our clients and they seem to revolve around a couple of topics I’ve yet to see addressed:

• Guidelines for selecting a Qualified Security Assessor (QSA) – while there are a large number of QSA organizations listed on the PCI Security Standards Council web site; they can’t really recommend a particular QSA for an individual organization.  This leads a lot of organizations to struggle with determining what criteria they should use in selecting a QSA for their certification.
• The role of the QSA – organizations are also still trying to understand the role of a QSA.  Should they get a QSA involved in the gap and remediation process in advance of certification?  If so, should it be the same QSA that will do their certification (knowing there’s a risk that the QSA will be pre-disposed to only care about certain vulnerabilities)?
• Industry-specific best practices – while each organization may have different infrastructures, in general, most industries try to be consistent with the major functions they perform.  So are credit card transactions handled differently between say, a major retailer with 10,000 POS systems and an insurance company that has hundreds of independent agents receiving remittances? Probably, so what are best practices around these industry-specific configurations?
• Virtualized environments – while the PCI Security Standards Council recognizes that some organizations have moved to virtual services for consolidation and management, the DSS really doesn’t provide guidelines for QSAs to evaluate and certify these environments.
• Monitoring and audit – while the PCI DSS recommends minimum timeframes for scanning, doing pen tests, etc. what are the real levels of monitoring and audit needed for ensuring security?  With the Hannaford and Okemo breaches that occurred (both where PCI compliant), neither discovered the problem until months after the breaches had happened.  So identifying what should be scanned and tested and if some of this should be on a continuous basis still requires refinement.
• PCI as part of an overall security model – what are the best practices around merging PCI security requirements into an enterprise’s overall security model?  Should it be maintained separately? Should some components be integrated with similar security mechanisms?  Should PCI be at the top of the security model and other configurations be based upon its requirements?  There are really no answers coming forth on this topic and the other question is where will they come from? Surely enterprises won’t expect the PCI Security Standards Council to tell them how to run their security services.

I will be providing Burton Group’s perspective on most of these questions in my upcoming report, but rather than relying on third parties to resolve these, I’d hope that the PCI Security Standards Council will be able to continue to provide answers to the questions they can in future updates, and releases, of the PCI DSS.