The details of the vulnerability aren't important, but basically it's a form of DNS cache poisoning. The DNS system is what translates domain names people understand, like www.schneier.com, to IP addresses computers understand: 204.11.246.1. There is a whole family of vulnerabilities where the DNS system on your computer is fooled into thinking that the IP address for www.badsite.com is really the IP address for www.goodsite.com -- there's no way for you to tell the difference -- and that allows the criminals at www.badsite.com to trick you into doing all sorts of things, like giving up your bank account details. Kaminsky discovered a particularly nasty variant of this cache-poisoning attack.

Here's the way the timeline was supposed to work: Kaminsky discovered the vulnerability about six months ago, and quietly worked with vendors to patch it. (There's a fairly straightforward fix, although the implementation nuances are complicated.) Of course, this meant describing the vulnerability to them; why would companies like Microsoft and Cisco believe him otherwise? On July 8, he held a press conference to announce the vulnerability -- but not the details -- and reveal that a patch was available from a long list of vendors. We would all have a month to patch, and Kaminsky would release details of the vulnerability at the BlackHat conference early next month.

Of course, the details leaked. How isn't important; it could have leaked a zillion different ways. Too many people knew about it for it to remain secret. Others who knew the general idea were too smart not to speculate on the details. I'm kind of amazed the details remained secret for this long; undoubtedly it had leaked into the underground community before the public leak two days ago. So now everyone who back-burnered the problem is rushing to patch, while the hacker community is racing to produce working exploits.

What's the moral here? It's easy to condemn Kaminsky: If he had shut up about the problem, we wouldn't be in this mess. But that's just wrong. Kaminsky found the vulnerability by accident. There's no reason to believe he was the first one to find it, and it's ridiculous to believe he would be the last. Don't shoot the messenger. The problem is with the DNS protocol; it's insecure.

The real lesson is that the patch treadmill doesn't work, and it hasn't for years. This cycle of finding security holes and rushing to patch them before the bad guys exploit those vulnerabilities is expensive, inefficient and incomplete. We need to design security into our systems right from the beginning. We need assurance. We need security engineers involved in system design. This process won't prevent every vulnerability, but it's much more secure -- and cheaper -- than the patch treadmill we're all on now.

What a security engineer brings to the problem is a particular mindset. He thinks about systems from a security perspective. It's not that he discovers all possible attacks before the bad guys do; it's more that he anticipates potential types of attacks, and defends against them even if he doesn't know their details. I see this all the time in good cryptographic designs. It's over-engineering based on intuition, but if the security engineer has good intuition, it generally works.

Kaminsky's vulnerability is a perfect example of this. Years ago, cryptographer Daniel J. Bernstein looked at DNS security and decided that Source Port Randomization was a smart design choice. That's exactly the work-around being rolled out now following Kaminsky's discovery. Bernstein didn't discover Kaminsky's attack; instead, he saw a general class of attacks and realized that this enhancement could protect against them. Consequently, the DNS program he wrote in 2000, djbdns, doesn't need to be patched; it's already immune to Kaminsky's attack.

That's what a good design looks like. It's not just secure against known attacks; it's also secure against unknown attacks. We need more of this, not just on the internet but in voting machines, ID cards, transportation payment cards ... everywhere. Stop assuming that systems are secure unless demonstrated insecure; start assuming that systems are insecure unless designed securely.

---

Bruce Schneier is chief security technology officer of BT, and author of Beyond Fear: Thinking Sensibly About Security in an Uncertain World.

Formalize Requirements for long-term use

Now that you are making security development a lifecycle, it is time to lock down and formalize your security requirements. At this point, you need to take what you’ve learned and begin translating your security principles into something that can apply to multiple releases and multiple levels of your development process.

At a product level, you need to use the security rules created in prior projects to define long-term security requirements. Those requirements will become your core security policies.  Then, at the version level, you should create security requirements that are version-specific and are defined by the security objectives and features you want to address in that version.

Both of these sets of requirements can be formalized in a way that makes them easier to transfer across future product cycles and to modify based on the unique features or security issues of each version.  Making these a staple of your development lifecycle will also ease adoption of these requirements as team become familiar with them over multiple releases.

I would like to touch on one topic before moving on – enforcing requirements. As your team grows and your SDL matures, there is an inherent complexity that comes with managing and enforcing your requirements. In our experience, we’ve found that it is critical to identify a security advisor. Up until now, your company has probably had someone championing security and best practices – either as a formal role or simply as a informal advocate. However, making it a feature of your lifecycle requires dedicated effort to enforce and sustain the requirements as well as monitoring the security ecosystem for changes that may add requirements to your process. The security advisor(s) are the people who will help guide the creation of the security requirements both broadly and for each product cycle; for a smaller team, this may be a single individual. For a larger organization, a team of people may be needed. The security advisor should also evaluate your security policy and apply changes where needed, ensure the product bug database is tracking security issues that can be reviewed later (I’ll get to the Final Security Review in our next post), and guide the definition and enforcement of a security “bug bar”.

Security requirements serve as the backbone of your SDL. The amount of effort you put in defining and enforcing requirements, and keeping them up to date with the current threat landscape will have a direct return on investment in the security and privacy of the product you create. Be careful to document and clearly communicate your requirements to your team, and use them as evidence when talking to your customers about how you ensure the security and privacy of your product.

Reference & Reuse Threat Modeling results & Attack Surface Reviews

Your developers and testers should have access to and be familiar with the attack surface analysis or threat model documents you have created. These documents are invaluable reference tools. Use them to perform evaluate your security from multiple angles:

·         Think about component-level architecture

·         List common pitfalls in writing code, or begin defining and building test cases.

·         Code reviewers can reference threat models and attack surface documents to verify specific attacks were addressed in the code.

·         Architects can use them to identify new areas of potential attack surface based on how new code is written or interacts with existing code.

·         Project leadership can reference threat models or attack surface documents to ensure the completed project meets all security goals.

Building a “live” library of threat models that is accessible by everyone and is designed to be easily maintained or updated is a big undertaking. Based on experience, I would strongly encourage doing this early in the evolution of your security lifecycle to avoid losing valuable data and to prevent the sheer volume of data from becoming unusable. I have heard of some companies using wiki technology as their library for threat modeling while others may use searchable documents, spreadsheets, or websites to store/sort/share the information. Whatever method you use, it is important to anticipate the accumulation of a large set of information that should be easily used and shared across the organization.

I would like to do a deeper dive on the importance of security code reviews as part of your “walk” evolution. Security code reviews focus on identifying insecure coding techniques and vulnerabilities that could lead to security issues. The goal of a review is to identify as many potential security vulnerabilities as possible before the code is deployed. The cost and effort of fixing security flaws at development time is far less than fixing them later in the product deployment cycle [from Improving Web Application Security]. You should create a process where top security developers actively review code within the context of known threats prior to deploying your code. Leveraging the existing documentation about feature design is a vital reference piece to make those security reviews successful.

Later this week, I’ll close the series with a look at final security reviews (FSRs) and how to document your work for post-release and next-release reference.

In the meantime, we’d like to hear from you:

?        How do you express your security requirements? Do you use a checklist, a whitepaper, or something else?

?        What challenges have you faced in enforcing requirements across your teams?

?        How have you implemented threat models or attack surface reviews?

Some of the major obstacles we face with 802.1X center around creating a smooth end user experience.  We, as integrators, have the distinct ability to make ‘whatever’ work- we find a way. But, what I hear most from my customers is “it has to be easy for the end user.”  (Sometimes they go on a little further, but I’ll leave it at that.)

Why does it matter?

Wireless, wireless, wireless. Although wired 1X is popular with our customer-base, the world isn’t quite flocking to it yet. However, 802.1X is certainly the best way to increase security and ease management of wireless networks. It’s standard, it’s flexible, it’s widely-supported by devices and endpoints and it eliminates the need for pre-shared keys or secondary passwords. It’s what most enterprises, government and educational organizations are implementing now, so it’s important.

What are some of the problems?

The end user will have some adjustments to make, and network admins and support desks aren’t always thrilled with the propect of re-training users for these expectations.

Because of non-disclosure and other confidentiality contracts with various partners, vendors and manufacturers, we’ve had sealed lips for almost exactly 12 months. Now that it’s been made public by the media, I can share a little information with you and explain why I think you should be excited.

What cat is out of the bag now? HP ProCurve’s network access control solution leverages endpoint management technology from StillSecure’s Secure Access solution. Information Week spilled the beans, so to speak, in Mike Fratto’s recent 2008 NAC Survey Analytic Report. (See page 32)

Now, at this point, I can probably lump you into one of three groups… 1) You don’t care or have no clue what this means 2) You care but think this means HP ‘has no NAC’… or group 3) You know about StillSecure’s success and ProCurve’s integration and think this is a great combination.

I’m sure everyone will have their own opinion- I happen to be in Group 3. Why? Because HP has taken the power of their servers, leveraged a very solid endpoint management tool and incorporated a variety of other management and security features by way of their identity management solution.

• The endpoint security. StillSecure’s Safe Access solution has been winning awards and earning stars for years. You can probably Google it, or check out some of Shimel’s blog  posts, such as this one, with 4- and 5-star reviews from SC Magazine. In fact, just this year (and in previous years) Safe Access was voted Best Endpoint Security Solution by SC Magazine and has won numerous other awards and accolades from various analysts and media firms. They have a clean, user-friendly GUI, a solid Linux platform and a variety of testing methods, deployment options and switch integrations. (And no, you don’t need ProCurve switches, the NAC integration is ready for your Cisco, Extreme, or whatever you have).

• User management. Combine one of the highest-rated endpoint security solutions with ProCurve switches, the #2 leader in the switching market (and Magic Quadrant resident) and the full integration with ProCurve’s Identity Driven Manager platform and you have one amazingly capable access control system. With ProCurve IDM, you can integrate directly with their NAC 800 appliance to offer per-user (or per-group) ACLs, QoS, restrictions or priviliges. Rules can be identity-based, time-based, location-based, or a combination of all. And, IDM eases 802.1X integration by offering users a central management and repository for user settings and VLAN assignments; it really is ProCurve’s special sauce and a distinguishing feature.

• Switch security. The integration of advanced switch security functions, such as DHCP snooping, Dynamic ARP protection and dynamic IP lockdown gives ProCurve another leg-up to fight common known attacks for both in-line and out-of-band NAC deployments.

• Zero-day protection. It gets better, the new Dynamic Configuration Arbiter (DCA) functions in ProCurve’s Pro-vision switches gives customers the unique advantage of integrating the NAC and IDM with ProCurve’s Network Immunity Solution (NIM). NIM uses flow analysis from sFlow and network behaviour anomaly detection (NBAD) to detect and automatically remediate on the edge. In English, that means we can use ProCurve’s NIM to detect attacks and take action at the edge port, such as blocking the port, locking out the MAC address of the offender, rate-limiting, or even mirroring the traffic to an IDS for further inspection. The super-nice part is, all the sFlow and NBAD works on wireless too. (Hey Stiennon, did you hear that?)

• Full integration. Unlike some of the other network-based NAC vendors, ProCurve has done an exceptional job of integrating these features and we’ll continue to see more integration in future revisions of the softwares and as more TNC/TCG integration frameworks are released (such as IF-MAP).

I think the strong integration with the infrastructure and the ability to leverage a mature endpoint integrity will make HP a ‘real’ player in the NAC market moving forward.

Not to knock other NAC solutions- Choosing a NAC is like selecting the perfect wine for your dish- there’s no 1 ‘right’ choice for all occasions. Each have their advantages and disadvantages. There are several that have special sauces and you’ll actually be seeing more on that soon…

# # #

This blog gives us a place to talk about our experiences from using the SDL here at Microsoft and hopefully provide useful information that will help you implement it more effectively at your company.  So, I would encourage you to use the Comments section at the bottom of each post to ask questions, give us feedback, or request other topics for us to cover.

Some quick definitions before we dive in. I’ve been using the imagery of learning to “crawl, walk and run” as a way to provide some basic starting points that would move your organization toward implementing the Security Development Lifecycle (SDL).  “Walking” is the point where your security development practices become a lifecycle – a repeatable, reusable process that makes security a part of your development culture. To relate the analogy to SDL a bit more closely, think of crawling as the “SD” in SDL. For this post, we’ll continue to talk about walking – or adding the “L” in SDL.

Let’s jump into another component for adopting the Microsoft SDL to expand your own Security Development Lifecycle.

Expand Security Training

Once you have management approval, it is necessary to gain grassroots acceptance of the changes – at the developer, QA/test, and PM levels. If you have been “crawling”, you have probably already implemented some sort of discipline-specific training around things like threat modeling, using compiler defenses, and fuzz testing. Now that you are building a lifecycle, your goal for security training should expand. Security training should be about creating an environment where writing secure software is everyone’s mission. While security training should be undertaken with the goal of understanding security issues and how to address them, good training (and instructors) will also explain why solving security problems is in their best interests and create an environment where they know voicing security concerns is encouraged.

Training has been one of the earliest and most important elements of the SDL at Microsoft. From our experience, we learned that the most effective approach is to divide your training into two tracks: general security principles and role-specific security practices. Before I jump into the details, I want to encourage you to also read Shawn Hernan’s very good post about SDL training that highlights some of the ways to make security training effective.

The general security principles should explain why security is important, how you define security requirements, the process you will use for writing and validating secure code, and how security relates to each phase of the lifecycle or unique roles contributing to the development process. A key factor for building a development lifecycle is educating your individual contributors on the value of investing in security. Of course changing culture takes time, but using the opportunity of structured training to explain your principles will be one of your most effective platforms for influencing change.

At this point in your organizational maturity, you are also beginning to expand your security thinking by focusing on each role in the development process. Discipline-specific security training is where you dig into the details of implementing a Security Development Lifecycle.

·         The developer needs to understand the practical details of how to write code securely, how to set compiler flags, what a security code review means, how to avoid using banned APIs, and what tools are available for them to perform security analysis before checking in their code.

·         The QA/tester needs to know how to set security rules in test tools, how to perform penetration testing, and what the security quality criteria is for your product, or how to file a security bug.

·         The PM needs to understand how to define measurable goals or how security policies can be factored into feature design.

·         The business decision maker of your organization should understand how to track security metrics alongside other product measurements or how security policy plays a critical role in the overall quality and value of your product.

·         Finally, it is critical for the employees occupying all job roles to understand the value of threat modeling – both as a tool for understanding threats early in the design phase and throughout the development process as a key barometer to the security pulse of your product.

Discipline-specific training will be the place to address these issues for your organization. In case you were wondering, all job roles should be required to attend both types of security training before working on your product.

Our new SDL website [http://www.microsoft.com/sdl] will be a very good place to watch for future training materials. The SDL Training and Resources page has some useful material up now and more will be coming in the future.

That’s Part Two. In Part Three, I will discuss the important “walk” components of formalizing security requirements and reusing threat models and attack surface reviews. Then we will close with the discussions on conducting final security reviews, and managing post-release documentation.

I’d like to hear if anyone is using the concept of “crawling” and “walking” to implement SDL in your company.

?        Do you provide security training to your employees today?

?        Do these additional training topics make sense in your organization?

?        What would you add to this that is unique to your application or company?

Assuring the security of the MetroCard system is a multi-layered effort encompassing technical solutions and procedures aimed at preventing unauthorized access and detecting unauthorized activities during the course of normal operations. The activity of the system is monitored for unusual behavior at many points in the operation. Procedures are in place to quickly respond to unusual occurrences in ways that not only limit risk, but can lead to immediate remedial action. NYC Transit is in the process of completing an extensive effort to become compliance [sic] with Payment Card Industry (PCI) rules relating to credit/debit transactions. While directly related to the business of accepting bank cards, these rules have also helped NYCT further harden its automated fare collection system against potential unauthorized access to sensitive transaction information by hackers and employees. In regards to your security related questions, which we will not address here in any detail, it is safe to say network environment is constructed in such a way that the serious security implications and vulnerabilities you reference do not exist.