Gunnar, All, (long I apologize) As I sat down to write (the fairly languished) Enterprise Security Architecture book I realized that process tie-in was essential. I realized that hope of configuring your containers let alone developing a secure application were lost unless the security goals were well laid out. The first two chapters I wrote, as a result, focused on distilling solid security requirements and tracing them into the high-level architecture and subsequently low level design. In short: I agree whole-heartedly that without solid security requirements, you're screwed. I also agree: anchoring such requirements in use (and abuse) cases is a good start to prevent dementia.
Below you'll find some additional "guides" beyond the advise to do use/abuse cases and wring security requirements out of them. Some of this guidance is contentious... I've found it works well for large organizations who fancy themselves "users" of software (despite their 1000-3000 person development teams ;)) ** Involve both security and business folk with use / abuse case generation** While your organization's security guys have hopefully immersed themselves in "thinking like an attacker", they don't often understand the real business impact of potential malicious behavior. Pairing business and security personnel together and using a risk management approach allows you to get at the doomsday and other high-value loss scenarios that threats might perpetrate against your business through a particular application. For instance: We deal a lot w/ credit card protection. Security guys always focus on the theft of credit card information. But, for most merchants the real pain point is an increased percentage surcharge on credit card transactions. This can create a reduction in margin far beyond the fine or PR loss associated with simple theft. With this impact in mind, what new business risks exist in your organization? How does this change the focus of your security efforts in the SDLC? ** Think about the partners, extranets, and the /real/ deployment when doing misuse** Several threat models, misuse, and abuse cases I've seen are done as purely pencil-and-paper exercises and don't take into account the interesting aspects of the application's real deployment. Overlooked items can include: partner networks, reporting and other batch interfaces, collocated (and sometimes more highly trusted) systems/components, administrative and other system-level interfaces, and so forth. Attacking the system is as easy as subverting its weakest interface, remember. And in doing so, an attacker might be able to pull the tablecloth (config, permissions, and data files, etc.) out from under an otherwise pristine use case. ** Consider specifics when doing misuse and abuse** When analysts do use cases, I've found they tend to simply users and roles. Does your organization think about data sensitivity classifications, collocated systems (from previous), roles, delegation of privilege, and entitlement when doing use, misuse, or abuse cases? With declarative access control coming more bolding into the picture (through Java and .NET) this becomes a terrible quagmire to overlook. Because most organizations don't even do this much, I'll omit some of the more specific follow-on guidance. ** Differentiate security requirements from security mechanisms** "Use SSL to encrypt Internet-based communications" is a terrible requirement, IMO. While it's important to think about security mechanisms for a variety of reasons, noting about the quoted statement indicates how to specifically protect data and from what threats. Thinking about the available mechanisms will help with feasibility, but it skips a few steps: 1) what are you trying to protect against and 2) what software and design must accompany the prescribed mechanisms in order to actually serve as protection. The easiest example of this is encrypted logs. Standard crypto foo, simply applied doesn't prevent duplicate log entries from outputting the same cipher text. This may be all the attacker needs to probe application state. Also: how does "use cipher XXX" assure that the developer will protect logs against truncation, partial deletion, and so forth. Are those requirements of the your system? ** Handle resolution of constraints separate from security goals** Requirements management meetings can turn into design meetings fast, relying on elements of design and feasibility to pin down requirements. There's something lost in these discussions: namely the stakeholder's security goals. Agreement as to the goals should occur first. Then comes distillation of requirements, then design. While organizations benefit from involving a gifted architect in requirements review, this person often can't bite their tongue when appropriate (to avoid sliding into design constraints land). Keep communication between architects and requirements analysts high, but remain formal about their hand off. Let analysts own requirements def., and keep them focused on the user's/system's security goals. Hand off to designers to get them to "sign up" to system construction, and only then deal with constraints. To go further into the particulars here, I'd have to inject a ton of change management text... So I punt here. This, IMO, leads to much more intelligent testing than "Is SSL enabled?" Check. By specifying requirements that speak to security goals and attack resistance, you've given testers more wherewithal as to how to stress the system, as an attacker would. ***Specific Tip: Leave no goal unexplored before beginning to architect. Do not use architecture definition as a mechanism for exploring software security goals. ***Specific Tip: Use your goals and high-level security requirements to excise security mechanisms or expenditure that goes well above-and-beyond your risks **Use Risk Analysis and Threat Modeling to Curb Security Requirements Explosion* Just as threat modeling and risk analysis can create security requirements, they can be used to constrain their unbounded growth as well. Risk analysis is particularly useful in determining whether or not you have too many (or onerous) security requirements) initially. Threat modeling, which requires at least initial design at its core, can help with requirements work during change management activities. Purely focusing on their requirements pruning potential, these two activities allow a development team to prioritize what attacks will possess the highest impact, and focus on requirements and design to address only these issues. So, this is just a sampling from a larger laundry list. But, hopefully it provides some more guidance to those whose appetites are whet from Gunnar and Johan's posts. ----- John Steven Principal, Software Security Group Technical Director, Office of the CTO 703 404 5726 - Direct | 703 727 4034 - Cell Cigital Inc. | [EMAIL PROTECTED] 4772 F7F3 1019 4668 62AD 94B0 AE7F EEF4 62D5 F908 > From: Gunnar Peterson <[EMAIL PROTECTED]> > > When I coach teams on security in the SDLC, I ask them to first see > what mileage they can get out of existing artifacts, like Use Cases, > User Stories, and so on. While these artifacts and processes were not > typically designed with security in mind, there is generally a lot of > underutilized properties in them that can be exploited by security > architects and analysts. > > The Use Case model adds traceability to security requirements, but > just as importantly it allows the team to see not just the static > requirements, rather you can the requirements in a behavioral flow. > Since so much of security is protocol based and context sensitive, > describing the behavioral aspects is important to comprehensibility. > > At the end of exploring existing artifacts, then there needs to be a > set of security-centric artifacts like threat models, misuse cases, > et. al. The output, e.g. design decisions, of these security-centric > models are fed back into the requirements in an iterative fashion. > > Security analysts and architects cannot do all the work that goes > into secure software development by themselves. There may be a > handful of security people supporting hundreds of developers. This is > why we need to educate not just developers on writing secure code, > but also business analysts on security Use Cases, requirements, etc. > (the main purpose of my article), testers on how to write/run/read > security test cases, an so on. > ---------------------------------------------------------------------------- This electronic message transmission contains information that may be confidential or privileged. The information contained herein is intended solely for the recipient and use by any other party is not authorized. If you are not the intended recipient (or otherwise authorized to receive this message by the intended recipient), any disclosure, copying, distribution or use of the contents of the information is prohibited. If you have received this electronic message transmission in error, please contact the sender by reply email and delete all copies of this message. Cigital, Inc. accepts no responsibility for any loss or damage resulting directly or indirectly from the use of this email or its contents. Thank You. ----------------------------------------------------------------------------