Security integration into Agile, Scrum,

[Krisboike]

Has anyone had any success integrating Security controls approval into Agile, Kanbon, Scrum, etc.  Pic your flavor of accelerated, sprint-based application development?  Especially when cloud-based architectures require new/major redefinition?  If so, any advise on how to do it knowing the culture would prefer to eliminate security controls in the first place? 

[Badfilemagic]

I'm involved with something similar right now, but it involves a wider agile adoption in a company that has hitherto been decidedly not agile. Because we're evolving our product architecture and our overall SDLC, it's a good time to ensure that security is integrated into the process.

Unfortunately, I'm not down the rabbit hold enough to provide too much insight, but I'm happy to share as I go along. Luckily, our dev organization has a sense that security is important, just little actual experience with it. Joined in a not-particularly-security-focused role, but as it has gotten out that I have that background and experience, I am being brought into the discussions and my role may change to explicitly own these things. It'll be a different up-hill battle, but I'll take well-intentioned ignorance over active hostility any day.

[Flyslinger2]

I was on a contract for a large Federal Agency to transition several of their systems to the cloud. Agile, Scrum and Kanban were all tools used in the process.  I'm not privy to the costs associated with the attempt-it couldn't have been small change.

It failed.  In all fairness I cannot DIRECTLY attribute the failure to the use of those tools.  That would be a stretch. However, in my 30+ years of being in software development I've never seen such an abject tortuous process as Scrum.  

Never, in any of the meetings that I attended was security brought up as part of the SDLC of this project.  Mind numbing.  Again, in fairness, the customer had a robust security group.  I didn't hear it in this project.

[Badfilemagic]

@Flyslinger2

I think your experience is all too common. Developers, who (hopefully) are generally smart and good at what they do, don't necessarily have the thought process behind security and designing it into a product or implementing it in their own modules.  Quality Assurance and test doesn't get the love it deserves in a lot of organizations, and with the move to agile it tends to go out the window, except for user-story-driven acceptance testing (if lucky). Most QA/test engineer folks, like most devs, aren't security practitioners. I know I am an exception to that.

Unfortunately, due to this, and the speed at which development is forced to move these days, we have far too few people focused on the security aspects of software and systems at the design phase and too many focused on implementing countermeasures and policies around broken systems. Using (ISC)2 membership counts as a proxy, we see that in the US alone, there are at current count 82,577 CISSPs and a mere 1345 CSSLPs. That's roughly 61x more CISSPs, most of whom are likely toiling away applying band-aids than there are CSSLPs who are, ostensibly, dedicated to helping squash today's bugs before they become tomorrow's CVEs (Obviously, CISSP is broader and overlaps with much of CSSLP, but the targeted nature of CSSLP speaks to the focus of those who have it).

I can't find counts like this from GIAC, but I would assume it is fair to say that there are far more incident handlers and intrusion analysts minted thus far than there are any of the secure development certifications.  Perhaps its because "threat hunting" and "pen testing" are sexier topics.  Perhaps its is because these career paths are more readily accessible to IT professionals who may not have gone through a computer science degree or other career path that lead them into development or even test.

I don't really know the answer right now, but I think that the problem is wider than the use or abuse of agile methodologies, be it Scrum or whatever have you.

[rslade]

> Krisboike (Newcomer I) posted a new topic in Tech Talk on 10-29-2018 11:02 AM in the (ISC)² Community :

> Has anyone had any success integrating Security controls approval into
> Agile, Kanbon, Scrum, etc.

Hmmmm.  Define "success."  Last time I saw any kind of security process central to an iterative style of development was in XP (eXtreme Programming), where the "pairing" gave you a sort of inherent audit function.

>  Pic your flavor of accelerated, sprint-based
> application development?  Especially when cloud-based architectures require
> new/major redefinition?  If so, any advise on how to do it knowing the
> culture would prefer to eliminate security controls in the first place?

It's pretty much got to be imposed from the top down ...  Oddly, though, when you do that, you do get buy in.  (And individual programmers re-inventing the waterfall method ...)

[RobertWohllaib]

I liked the book below which goes over being a security body in an Agile environment and ensuring your req's are met.

https://www.amazon.com/Agile-Application-Security-Enabling-Continuous/dp/1491938846?keywords=appsecd...

[wimremes]

Yes. It can be done. 

Before I go into detail, I'd recommend you to start here : https://www.microsoft.com/en-us/SDL/Discover/sdlagile.aspx

1) As the security guy or the security team, you have a consulting function in this process.

2) The development teams need to own security.

3) Teaching developers to apply threat modeling from the design phase is the hardest "shift left" you can make

4) Just like general security being dependent on sound IT practices, application security is dependent on sound development practices. A proper CI pipeline, source control, etc. are key to building security in.

5) Automate where you can. Learn from penetration tests to build abuse cases into your QA framework. Move from there to implement automated testing (SAST).

6) You will always start with squashing individual bugs but you need to mature to a level where you focus on bug classes. Once you can do that (e.g. generalize bugs to bug classes so you can address them with design/architecture changes rather than just fixing bugs), you have a process that works. 

[wimremes]

Oh ... I forgot checklists. Developers are experts in choosing the languages and tools they need to build the functionality required. It is not security's role to tell them to "use Java" or "use Go", etc. We provide them with checklists for security depending on the purpose of the functionality/application they are working on. How they implement it and with what should be their choice. Checklists work wonders.

[Badfilemagic]

@wimremes

Thanks for the explicit wisdom on this. This tracks with what the dev group I immediately work with and I are doing, but getting it out to the rest is also a function of their adoption of agile more broadly, which is a larger set of challenges in workflow.  I'm fairly new to agile myself, so that puts me in a state where I am less sure of myself that I might otherwise be.

I like this list, and the link. This will be a great help!

[mgorman]

One question is, what do you consider part of the Agile, Scrum, etc. process and what is outside of that, but still part of the SDLC?  If the process is being done properly (and that is a HUGE if), then you should be able to place controls in the system with items built into the pipeline, like SAST, with a pass/fail based on scores or whatever else you need to that is relevant.  Automated vulnerability scanning against an integration environment can help to find errors as well.  Tools like this give some opportunity to have the discussions as to why things are failing.  As with all things security, the key is to get management buy in in advance.  If the SAST scores need to be 80, or B, or whatever they might use, then get that in a written policy.  Sa,e with vulnerability scanning, whatever tool you might use, set a standard, no software is allowed with P1, or more than 1 P2, whatever is proper in the environment.  That gives you a backstop, then you can turn the conversation to things like training, programming patterns, etc., when people complain about the delays.  If the management has said this is the standard, then the goal for development has to be "How do we meet our deadlines while also passing these gates?", rather than how do meet the deadlines alone.