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

Pseudorandom thoughts on how to make the best of Agile

Agile is not an ideal development methodology from a security perspective, but then again - what is? the Agile family of methodologies represent the dominant approach to building software today. In some ways they are quite helpful to security, not when compared to theoretical SDL approaches but when compared to actual, real world alternatives. So while Agile is not the be all, end all from a security viewpoint, as your Mom told you - make the best of it. Here are some things that work well in many Agile projects


* Test focus - this is easy. From the beginning Agile, XP et al emphasized Test Cases over almost everything else. This actually plays well with infosec's primary strength - white box and black box testing, putting the tools to work here make sense assuming that we can cope with...

* Short release cycle - infosec must be able to deal effectively with fast iteration of Agile projects, being ready to execute vulnerability assessments every few weeks, automation is a must have, and this is possible if you have...

* Dedicated staff - infosec needs team members dedicated to Agile projects, in the same way DBAs are assigned to support developers, infosec must assign appsec people to work with specific projects. To make this work, the security team must change from its traditional structure. The infosec team cannot sit in a separate group that checks in once a month or less frequently with development teams, they must be way more engaged with a infosec person carving out dedicated time to each project. Infosec should have a representative identified for each Agile project, they may not be in each and every daily Scrum meeting (though this is ideal) but they need to know the feature list, backlog list, prioritizations and other project drivers as well as everyone else on the team

Staffing up to deliver on the above positions infosec to get some ancillary benefits by being embedded with the project teams: 

* Emphasis on roles - one strength of Agile is a focus on actor roles, this is a good head start on working on RBAC models for applications

* Close communication - helps to understand dev team priorities, and what and how much security is potentially going to be able to ship with which release. Visibility into what else is in the bug list

* Short release cycle - less time to to identify issues

* Heads up on what is shipping - gives better view into the assets that are being deployed, ability to inventory what may need to be fed into operational monitoring systems, and IAM

* Discover dependencies -whiteboards don't crash, but code does. Often not thinking through dependencies is the root of future problems, so being close to the ground with the development teams is essential to shake out these issues early 

Permit me to dream, a bit. The issue in Agile, and all other methodoloigies, that always comes is the negative requirements that security has in spades. The long list of things we don't want to happen, these can be expressed via Threat Models, Misuse Cases and non-functional requirements, but these rarely fit well in an Agile project. Checklists can help to fill this gap by enumerating known bad ways to do things and giving specific guidance on how to avoid.

So Agile is not be everything you need for a successful appsec program, but most security teams do need to figure out how to work with Agile to make appsec happen. What have you seen be successful (or not) in Agile appsec?

May 31, 2012 in Agile, Security | Permalink | Comments (3) | TrackBack (0)

App Security at QCon

The first App Security track is in full swing at QCon. I have to hand it to the folks at InfoQ and JAOO, they might be the first big development conference to take a real shot at doing a full blown app security track. Right now, Jeff Williams is presenting an Enterprise Security API (sorely needed for consistency and integration), which is slated to be released next week at OWASP's conference. The slides for the App Security track are all being added to the QCon site.

Kent Beck did a keynote and two of the main points he stressed were developer accountability and transparency. This was a perfect lead in to Brian Chess' presentation on static analysis, which remains one of the cost effective and scalable app security tools we have.

Next, John Steven presented some advanced threat modeling techniques, because this is a developer conference in 2007 most people haven't done threat modeling so it was a learning experience with a lot of real world q&a. The responses from developers who heretofore have not focused too much on security has been really positive which is nice to see.

There have been some great sidebar conversations. There are a lot of agile disciples here (of course), and they are somewhat concerned about how (and how much) security to add in to their process. This gave me a chance to reference one of my favorite papers of the year - Johan Peeters and Paul Dyson's paper on Cost Effective Security, which sorts out app security concerns in an agile way.

November 07, 2007 in Agile, QCon, Security | Permalink | Comments (2)

Cost Effective Security - Avoiding the Bridge to Nowhere

I am really happy to say that the latest IEEE Security & Privacy Journal (subscribe if you don't already - $29/year), has a great article called Cost Effective Security, its by my friend Johan Peeters and Paul Dyson. It is not really possible to overstate the importance of cost effectiveness in security. The classic IT security approach of "its perfect or its broken" is a bridge that leads nowhere. Its not a strategy for security, its a CYA. If you can't operationalize and implement your security strategy, then you don't have a security strategy. Its all about tradeoffs, ideally in some sort strategic context that helps you make progress over time, like a security architecture blueprint.

This is what makes me grateful that Johan and Paul wrote Cost Effective Security, they understand the logistics of software development, and describe ways to move forward and improve security in the real world. Additionally, they show how to account for security in an Agile process so it is not just a Big design up front exercise. One of the main issues, the authors tackle is the art and science of creating abuser stories and associating them with user stories in an Agile process. This is very important for three reasons.

1) It gets security out of the passis auditor only mode, where they come in and a) bless or b) complain about a system; and into an active collaborator and implementer -- this is the future for security groups who want to add value to their enterprise.

2) It gets security involved on day 1 of the development project, not the last week before go live when it is too late.

3) It helps security make real, live business tradeoffs anchored in a business value assessment.

The anchoring is provided, not by a "perfect security policy", but by understanding the user stories and their business goals, and then mapping abuser stories to them.

The specification and prioritization of nonfunctional requirements has so far been a somewhat black art in agile development projects. Agile’s fundamental goal is that development projects should deliver systems that are “fit for purpose” rather than ones that deliver grand technical solutions at the expense of functionality or fail to deliver anything at all, but the definition of "fit for a purpose" must include the system's non-functional requirements.

Agile is about early delivery of business value, security needs to get out of the ivory tower, stop building bridges that lead nowhere, and into the business of delivering value, security services that exist in a business context.

1447940840077319230s425x425q85

See Johan's blog on "Dreams and Nightmares" for some additional thoughts on associating non-functional requirements in an Agile project.


June 07, 2007 in Agile, Security | Permalink | Comments (2)

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)

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