1 Raindrop

Gunnar Peterson's loosely coupled thoughts on distributed systems, security, and software that runs on them.

Recent Posts

  • Security Champions Guide to Web Application Security
  • Security > 140 Conversation with Pamela Dingle on Identity
  • 6 Things I Learned from Robert Garigue
  • The Curious Case of API Security
  • Security Capability Engineering
  • Ought implies can
  • Security > 140 Chat with T. Rob Wyatt on MQ and Middleware Security
  • Privilege User Management Bubble?
  • The part where security products solve the problem
  • Four Often Overlooked Factors to Give Your Security Team a Fighting Chance

Blogroll

  • Adding Simplicity - An Engineering Mantra
  • Adventures of an Eternal Optimist
  • Andy Steingruebl
  • Andy Thurai
  • Anton Chuvakin
  • Beyond the Beyond
  • cat slave diary
  • Ceci n'est pas un Bob
  • ConnectID
  • Cryptosmith
  • Emergent Chaos: Musings from Adam Shostack on security, privacy, and economics
  • Enterprise Integration Patterns: Gregor's Ramblings
  • Financial Cryptography
  • infosec daily: blogs
  • Jack Daniel
  • James Kobielus
  • James McGovern
  • John Hagel
  • Justice League [Cigital]
  • Kim Cameron's Identity Weblog
  • Krypted - Charles Edge's Notes from the Field
  • Lenny Zeltser
  • Light Blue Touchpaper
  • Mark O'Neill
  • Off by On
  • ongoing
  • Patrick Harding
  • Perilocity
  • Pushing String
  • Rational Survivability
  • rdist: setuid just for you
  • RedMonk
  • RiskAnalys.is
  • Rudy Rucker
  • Software For All Seasons
  • Spire Security Viewpoint
  • TaoSecurity
  • The New School of Information Security
  • Windley's Technometria
  • zenpundit
Blog powered by Typepad

Johan Peeters on Dreams and Nightmares

Johan Peeters' Thinking Aloud blogs on the unforseen challenges of security in the SDL, specifically focusing on the challenges of dealing with security in an Agile approach:

The question is not whether and when to let economics guide planning as opposed to technical considerations. In the end, economics always win. The problem, in my view, is that we tend to see the value of a new feature, but not its cost. By cost, I do not mean the effort we need to invest into implementing the feature, but rather the cost of the nightmare scenario's that may execute as the system offers some new functionality.

This is am issue that stymied many a security mechanism. One way to look at this issue is to develop Misuse Cases that show the system from an attacker point of view in parallel with user story development, which show features and functionality. The advantage of a little extra effort spent in desgn becomes clear during future iterations and operations

Like functional requirements, non-functional requirements deserve to be revisited at each iteration. It may be comforting to think that, if you get it wrong, you get a second crack at the whip. On the other hand, you are never really done since new non-functional requirements may emerge throughout the duration of the project and old requirements that were initially deemed of secondary importance may take on an increased significance.

How many times have you seen authentication and authorization mechanisms that are weak, broken, or don't reflect a current threat model (hi MQ Series!)? But by the time the system is in production or just close to go live, it is too hard/too late to rip out all the authN and authZ because these require a full system test cycle, and so on. The examples from Johan Peeters and Paul Dyson's workshop are focused on Agile, but these issues apply across all software development methodologies.

**************************************************

Upcoming public SOA, Web Services, and XML Security training by Gunnar Peterson, Arctec Group
--- NYC (April 19), Unatek Web Services (May), OWASP App Sec Europe (May), Helsinki (June), DC/Baltimore (July 19).

April 03, 2007 in Agile, SDLC, Security, Software Architecture, Use Cases | Permalink | Comments (0)

Essential Factors for Successful Software Security Awareness Training

The current issue of IEEE Security & Privacy Journal has an article by John Steven and Ken van Wyk regarding how to get development and security staff to co-evolve towards better software security. They get right to the heart of the issue:

Developers fulfill the single most important role in software security: they build the software. Yet, it’s very likely that all but a handful of an organization’s developers are completely blind to how the software they’re building or maintaining today could be exploited tomorrow. A predictable consequence is that developers can’t build security into their applications and often push back heavily on any security analyst who takes a pot shot at their code.

This is part of the tension that exists between all operational and development groups, operations staff are typically suspicious of what the developers are throwing over the wall into production, in security we have the additional case that new vulnerabilities and exploits are discovered over time.

The authors discuss mitigating some of the core issues through training. As someone who does security training, I particularly like their suggestion that training should be seperated based on audience:

  • Executive training should teach the difference between software security and conventional network security approaches, particularly the pervasiveness of software security issues. It should also present and align business owners with the ESSF. Finally, it should establish short- and medium-term goals for software security capability, as well as set group owner expectations, means of measurement, risk management goals, and MBOs.
  • Management-level awareness training should teach development managers how to make schedule, cost, functionality, and risk trade-offs via a risk-management framework. It should also demonstrate how software security touchpoints affect development methodology. Finally, it should equip managers with knowledge collateral and questionnaires to validate the probability and impact of security findings and mitigation strategies.
  • Awareness training for development and security staff should seek to transform the way developers behave when they return to their development environments. It should further show how to execute software security touchpoints to build security in to the development life cycle. It’s also vital that it clearly shows how attackers exploit software and how to resist attack. Finally, it should provide analysts with a toolkit of specific attacks and principles with which to interrogate systems.
  • One of the big challenges in training is targeting the message correctly. Even in the technical software security training sessions I do, I typically see a mix of app arch, app dev, traditional security (i.e. network) staff, and operations. A large part of the challenge is making sure the software people understand enough about security and that the security folks understand enough about software.

    As with many big challenges, software security is not going to be solved with one magic tool or technology, instead it is a mix of architecture, process, and organization. Training and awareness runs through all of these.

    September 27, 2006 in SDLC, Security, Software Architecture | Permalink | Comments (0)

    Secure Your SOA: Web Services and XML Security at OWASP Europe

    4/30 is the last chance for early registration for OWASP Europe. I will be teaching a one day class on Web Services and XML security -- the class focuses on the risks inherent in this programming model, what the standards are, how to use them, and where you still need to use custom code and configs to deal with the security issues. This is a variation of the classes that I provide for customers onsite

    April 17, 2006 in Computer Security, Deperimeterization, OWASP, REST, SAML, SDLC, Security, Security Architecture, SOA, SOAP, Software Architecture, Web Services, XML | Permalink | Comments (0)

    Building Security In

    Gary McGraw's latest book "Software Security: Building Security In" is now released. Great, informative read, I will blog more on it later. As with other of Gary's works, it explores new territory on collaboration among key development stakeholders. This book has sections which are more accessible to non-developers, e.g. testers, BAs, making it all the more valuable. Some points discussed include:

    • Code review using static analysis tools
    • Architectural risk analysis
    • Penetration testing
    • Security testing
    • Abuse case development

    Like I have said many times before, everyone talks about adding security in to software, but few discuss practical techniques to do so. This book does.

    February 03, 2006 in SDLC, Security, Software Architecture | Permalink | Comments (0)

    Getting Lawyers to Do Our Work For Us

    One of my favorite OWASP projects is the OWASP Legal Project. Jeff Williams, the project lead, described this project to me as "getting the lawyers to do our work for us." We are at a point now where the demand for security services is increasing. As many experts like Dan Geer point out, we will not be able to train new security people fast enough to deal with the demand. So, one way to mitigate this is to have security teams provide prescriptive guidance that other groups can execute. Of course when you delegate things like this, you would like to delegate to someone who can make things happen. Lawyers have their uses...in outsourced development, contract negotiation usually represents a point of maximum leverage for companies to get their requirements met. Lawyers usually lack the developer foo to know what should be specified in the contract. The OWASP legal project provides some excellent guidance for companies to do just that. With a minimum of awareness and technical support provided by development and security groups, lawyers are empowered to write much more effective contracts from a security standpoint. Or in other words do at least some of our job for us.

    This contract Annex is intended to help software developers and their clients negotiate and capture important contractual terms and conditions related to the security of the software to be developed or delivered. The reason for this project is that most contracts are silent on these issues, and the parties frequently have dramatically different views on what has actually been agreed to. We believe that clearly articulating these terms is the best way to ensure that both parties can make informed decisions about how to proceed.

    As John Pescatore, a research director with Gartner, put it:

    "The security of commercial software will improve when the market demands better security. At a minimum, every software request for proposal should ask vendors to detail how they test their products for security vulnerabilities. This step will start convincing vendors of off-the-shelf software and outsourced developers that enterprises value security."

    The contract project deals with: requirements and lifecycle, personnel, environments, testing and acceptance, assurance, reviews, and more. Tell your leadership and legal team about this today!

    February 02, 2006 in Deperimeterization, Legal, Open Source, OWASP, Risk Management, SDLC, Security, Security Architecture, Software Architecture | Permalink | Comments (0)

    Web Services and XML Security Training at OWASP Europe (Belgium)

    I will be teaching a one day course on Web Services and XML Security at the OWASP Europe conference. I enjoy the OWASP conferences, there is a good mix of security folks, developers, and architects, plus it is vendor neutral, many different industries are represented, and usually in a nice location.

    The focus areas of my class are:

    • Web Services attack patterns
    • Common XML attack patterns
    • Data and XML security using WS-Security, SAML, XML Encryption and XML Digital Signature
    • Identity services and federation with SAML and Liberty
    • Hardening Web Services servers
    • Input validation for Web Services
    • Integrating Web Services securely with backend resources and applications using WS-Trust
    • Secure Exception handling in Web Services

    The class explores standard secure coding and application security issues and looks at new risks and countermeasures that are present in Web Services, SOA, and XML paradigms.

    January 24, 2006 in Deperimeterization, Federation, OWASP, Risk Management, SAML, SDLC, Security, Security Architecture, SOA, Software Architecture, SOS, STS, Web Security, Web Services, XML | Permalink | Comments (0)

    Service Oriented Security Architecture

    My paper on Service Oriented Security Architecture from the Nov. issue of ISB is now online. The paper describes an approach to dealing security design and architecture issues in developing Web Services and SOA software.

    The primary goals are to illustrate a set of key analytical areas, and a way to synthesize these relationships. As Kruchten and others observed separation of concerns is an useful technique in software architecture. In security architecture, it is useful as well, and in addition separation of assets yields a more robust risk management model. In the case of this paper, the assets are separated as Identity, Message, Service, Deployment Environment, and Transaction. This way the risks and countermeasures can be understood and the elements and constraints dealt with in their own domain to the extent possible.

    January 19, 2006 in Deperimeterization, Federation, Identity Services, SDLC, Security, Security Architecture, Separation of Assets, SOA, Software Architecture, SOS, Use Cases | Permalink | Comments (0)

    Phasing Security into the SDLC - A Comparison of Approaches

    :Lots of companies talk about adding security into their SDLC; Microsoft recently found a security bug and working to address it in the future in their SDLC. Feeding security issues forward is a great idea, but there are problems to be solved and decisions to be made about actually deploying security into the SDLC. The major SDLCs, like XP and RUP, do not have a concrete notion of security, security is treated as just one more non-functional requirement. So it can be hard to get traction on adding security into your SDLC. One of the benefits of being a consultant is that pragmatism is beaten into you. As great as it would be for organizations to unilaterally adopt security throughout their entire SDLC, many companies require a phased approach. There are several contributing factors to this: organizations typically can only absorb so much change at once, the domain is not broadly understood, and the developer-to-security personnel ratio is skewed heavily in favor of the former.

    BuildSecurityIn, my own work on security describe how to deploy security techniques into your SDLC from an end to end standpoint, this is the end game. In many cases, a phased approach is needed to advance. Let's take a sample SDLC that includes Analysis (Requirements, Use Cases), Design (Data Modeling and Flows, Modeling), Coding (Development and Unit Testing), and Deployment (QA, System Test, Production Promotion).

    If deploying security across all of these phases is not feasible in the near term, or if an iterative phased approach, where "centers of excellence" are developed at discrete points in the process, is desired here are some approaches to phasing security into the SDLC:

    1. Top down Approach
    This approach adds security requirements to the functional and non-functional requirements and the Use Cases. These requirements can be derived from the Information Security policy, and meeting with security stakeholders. These policy statements are mapped to the requirements and Use Case documents. The requirements drive the design, development and testing of the system. Strengths of this approach are that requirements are clearly defined, and the implementation is up to the domain experts who can make the design and development decisions that work the best in their own technology space.

    Key indicators for use: If the organization has a clear Information Security Policy that addresses issues like data classification and acceptable use in a way that can be translated into requirements then this approach can be a good starting point.

    Risks in this approach: The Information Security group is outsourcing design and implementation decisions, and lacks an overall compliance view.

    Mitigate this risk by writing Security-centric Use Cases that show behavioral flows, exceptional flows, and pre and post conditions that provide more specificity for designers, developers, and testers. Getting actionable security requirements into developer's hands from the early stages is a huge advantage towards seeing them realized in production. Additionally, exorcise the word "security" from as many requirements as possible and be more specific around the actual goal, e.g. authenticate a user dont' "secure a user"

    2. Testing and Validation Approach
    The top down approach gets Information Security involved at the begining of development. The testing and validation approach targets the end of the development lifecycle. Security systems testing, penetration testing, white and black box apporaches can be used to validate the sufficiency of the system to meet the security goals.

    Benefits of this approach are that the Information Security group has a better handle on the qualities of the code that is to be deployed and can find implementation flaws. The drawback is that there may not be time to fix all of the issues that are found. One of the recursive issues at play here, is if the Information Security Policy is not clearly defined, then what is the testing criteria? Industry best practices such as CIS, SANS and OWASP usually fill this gap.

    3. Start in the middle approach
    This approach focuses on code review and testing during the development phase. Using peer review and automated source code analysis tools to identify security bugs in the code as it is being developed. The Source Code Analysis Tool landscape has gotten a lot more interesting in recent years, making this an interesting approach. The advantages include: being involved early enough to both find *and* fix security bugs, and providing informaiton about bugs to developers in a language that is understandable to them. The disadvantage is that some security errors may be at a design level and it may be too late to resolve these, also the lack of a clear policy and standards may have the smae gap as with the Testing and Validation approach.

    A fourth way that may be combined with anoy of the above is training in the SDLC. Focus on a center of excellence in one area and train the subject matter experts on mapping secuirty to their space for the reamining areas. This approach decentralizes some control and empowers domain experts to make the correct design and implementation choices. Again, policy and/or standards are important so that there is clarity around the goals, the technique by itself is never enough.

    Remember these are starting points, not the end game. The whole point of a phased approach is to *not* boil the ocean. Phased approaches are an example of an approach I advocate because it forces InfoSec to operate (and iterate) like a software development team

    January 10, 2006 in Risk Management, SDLC, Security, Security Architecture, Software Architecture, Use Cases | Permalink | Comments (0)

    My Photo

    SOS: Service Oriented Security

    • The Curious Case of API Security
    • Getting OWASP Top Ten Right with Dynamic Authorization
    • Top 10 API Security Considerations
    • Mobile AppSec Triathlon
    • Measure Your Margin of Safety
    • Top 10 Security Considerations for Internet of Things
    • Security Checklists
    • Cloud Security: The Federated Identity Factor
    • Dark Reading IAM
    • API Gateway Secuirty
    • Directions in Incident Detection and Response
    • Security > 140
    • Open Group Security Architecture
    • Reference Monitor for the Internet of Things
    • Don't Trust. And Verify.

    Archives

    • November 2015
    • October 2015
    • September 2015
    • August 2015
    • July 2015
    • June 2015
    • May 2015
    • April 2015
    • March 2015
    • February 2015

    More...

    Subscribe to this blog's feed