Keeping the balance between information security assurance and business goals has always presented itself as a big challenge for any senior industry specialist. As companies have grown and progressed over time, this has resulted in more and more lean organizations implementing agile methodologies across their IT practices. As a natural reaction, these companies have fit additional processes within those new practices to further improve quality, scalability, and information security risk posture.
Introduction of agile methodology for most companies has shown to be extremely successful and enabled improvements of speed, collaboration, and visibility across different teams and departments. Applying agile philosophy to retain cohesiveness across enterprises is far from easy, but trying to integrate new processes with different sets of activities into existing agile culture and workflows might present an even bigger challenge.
It is extremely important to understand that “doing agile” and “being agile” are two different kinds of animals. The same analogy can be used for Information Security, where “doing security” doesn’t actually mean “being secure.” It is about culture in both cases, but integrating information security into an agile software development cycle requires significantly different strategy from conventional approaches.
It usually includes custom workflows along with specific integration steps into processes throughout multiple phases (i.e. usually starting from portfolio Kanban towards MVP development). Traditional human centric approaches with limited skill-set pools or fully tool reliant security assurance solutions have shown to be inadequate to cope with ever-evolving threats and fast pace that current development methodologies are dictating.
Crowdsourcing obviously offers several advantages involving mass intelligence to solve all sorts of different problems. Unlimited skill-set pools and a constant stream of new talent from around the world has definitely gone through a rapid evolution. Reluctance based on fear of managing overhead and risky business, in general, is now slowly fading.
More and more companies within different industries are relying on crowdsourced services, and why should information security be the exception? Confidentiality? Trust? When talking to other IT professionals these were the buzzwords used to describe their concerns. However, after a short conversation it is apparent that these individuals are using crowdsourced services for majority of their other daily needs. Using Uber for transportation, ordering food from Forkable, re-designing their house through CoContest, and even recruiting from Reflik. So why not crowdsource their security needs?
It is obvious that there is a paradox around this discussion, and I think it is also obvious that everyone should encourage others to peek into the future of information security and become part of it. By simply revealing a few general facts and benefits of these approaches that other industries are already applying and cashing in on big-time.
A simplistic process, constant education and awareness of developers, full workflow integration, as well as scalability and flexibility when it gets to remediation planning and re-assessing the risk posture are just a few of the advantages to crowdsourcing.
Looking at some fairly old agile SDLC security assurance models and ideas published in the article “Towards Agile Security Assurance” by Beznosov and Kruchten — which describes the agile phases and necessary coverage from the information security perspective within them quite well — it would be interesting to try and imagine where a crowdsourcing approach could add value and enable better security assurance. Going through this flow also gives us a good overview of how little things have actually changed over the past years.
Iterative lifecycle is obviously working well for most organisations, but the fact of the matter is that these days 86 percent of web applications contain at least one ‘serious’ vulnerability (WhiteHat Security’s “2015 Website Security Statistics Report.”). We must have been doing something wrong then, right? Requirements phase, design, development, and testing along with integration and deployment should definitely include some level of info-sec involvement. Also there is simply no reason crowdsourcing can’t integrate into all of them and provide a better and faster risk remediation strategy.
Let’s quickly dive a bit deeper into agile development cycle stages, and ask ourselves some fairly random logical questions that are directly or indirectly related to the doubts and challenges we are all facing:
Awareness and Training
Do you think your dev’s are interested in those, dated OWASP Top 10 slides they have to look at each year, just so they can check that box off the list?
Requirements
How hard is it to create effective security gating with bug bars? How difficult is it to get adequate advice at the right time to successfully perform security and privacy risk assessments while relying on one or two already heavily overloaded internal resources?
Design
Do you have a dedicated security architecture resource locked and loaded — just waiting on your agile cycle to get into this stage so he can show his brilliance when it gets to leading edge authentication mechanism design, reduction of the attack surface, or threat modeling exercises?
Implementation
How much time has been wasted, and how many deliveries delayed by endless tasks of eliminating all the false positives that are generated by various source code analysis tools. How comfortable is it to rely on average security engineers that unfortunately speaks only Java and PHP, but don’t play well with your latest friend Ruby?
Verification and Release
External, 3rd party penetration testing companies have loads of expensive tools and fuzzing scripts so they can fuzz our web applications and API endpoints thoroughly and we’re good to go once they assess us in pre-release stage. Do they? Can they?
Regular Assessments and Response
Should we stick to one company to regularly assess our applications or should we switch it up every time? How many testers should be engaged and how diverse should their skill-set be? Once we get the final report will they track our remediation process and re-test our application whenever we like?
Crowdsourced information security has a lot to say about all of these questions, and it has much more to offer than most people in the industry are aware of. Then what does it take for organizations to muster up the courage to ride the wave, instead of standing aside and observing it with skepticism?
There is an old saying that goes, “Who will not be deceived must have as many eyes as hairs on his head’’. At this point in time, crowdsourcing may be the only way we can get as many eyes as hairs on our heads. As well as be the ultimate path towards making our SDLC processes and the applications we develop more secure and suitable for today’s threat landscape.
