Share
Over the years, a gap has emerged between application security and business development. With the introduction of Agile and DevOps, this gap has become painfully evident. Suddenly, business development becomes genuinely impeded by exhaustive information security policies with their checklists and penetration tests. The challenge businesses are now facing is how to bridge this gap.
The term “risk” has taken on an inflated meaning, and it is often used as a fashionable buzzword that no longer has a connection with actual threats. Nowadays, when a new vulnerability is identified, it has become almost normal to launch a full-blown marketing campaign complete with fancy names and logos, dedicated websites, and a loud social media presence. Risk is no longer an indicator of something negative but has become a catalyst for pushing “money-making silver bullets” on customers. On the other side of the risk equation, hackers are seen as “smart guys” with elite skills, while the reality is that most breaches occur as a result of simple mistakes and decades-old problems. Tool vendor solutions offer products and services that are no longer adequate for dealing with the fast-changing world of today. Most of these services rely on stopping or identifying known attacks. In a world that is changing practically every second—and especially in our world of IoT, mobile devices, and cloud solutions—the ancient “castle and archers” approach to defense no longer works. The evidence of many successful breaches shows that advanced exploits weren’t even required to hit pay dirt; misconfiguration issues or simple human error was all it took. If an attacker is able to access one of the maintenance or configuration parts of your system, it’s game over. If an attacker can access a scripting environment, game over. If an attacker can lure one of your employees to click on a link and go to a website or install something: Game Over.
In many companies, there is a huge gap between the security operations and the business development departments. Often, internal security guidelines are barely aligned with the rest of the organization and are therefore frequently bypassed or ignored. The security operation team’s natural response to this is to push the guidelines even harder, which only further widens the gap. The security and development teams appear to approach the business in two very different ways—one wants to build with bricks, concrete, and steel, and the other wants to use Lego and Meccano.
Today, both the InfoSec industry and clients have enough money and attention to change this situation, so we should ditch the bolted-on, technology-driven approach and start focusing on talent and smart actions. When we look at the root causes of many hacks, it’s not technology that is to blame but instead ego, culture, miscommunication and the working environment. As long as security is considered as something to be added on or hired, it will fail. We should once again consider security to be a standard quality attribute, for which everyone is responsible. Fortunately, this challenge is easier to solve than it appears to be. The key to success here is to split the security officer’s responsibilities into more Agile-minded roles with different responsibilities and duties.
History shows that speed always wins over certainty. Even when you are wrong while being fast, you will still have more time (and therefore chances) to make corrections and, in the end, you will win. Assembly lines, workflow software, Lean, Agile, DevOps, and all other speed-improving approaches won out over the old ways and will continue to do so in the future. The solution to the security vs. development struggle is not to slow down or add more tollgates to development. Instead, security must start understanding how the new world works and it must find new ways to regain its grip on the situation. In the end, it’s more effective to achieve 80% security with 100% alignment, than attempt to reach 100% security with 0% alignment, especially if you have plenty of opportunities to make adjustments.
In the Agile way of working, the product owner is the person who translates business and customer desires into work items (user stories) for the teams. The actual desires and requirements, however, are provided by the stakeholders. Therefore, it is logical that a security officer will start acting like a security stakeholder. As a security stakeholder, you will have to compete with other stakeholders when user stories are prioritized, so it becomes important to be able to translate requirements into real business value and switch from a reactive approach to a proactive approach. As a security stakeholder, however, you probably won’t be able to bring many delighters to the table. In fact, most of your requests will not even be satisfiers. The line you find yourself walking most often is of the dissatisfiers—the stuff nobody cares about until it’s not there. On a positive note, however, often these are also the requirements about which there is little dispute of their importance.
In most companies, the ratio between security-minded people and non-security-minded people is way out of whack. Security teams should, therefore, start acting as supporters and trainers. As these teams become more visible within the organization and start to align with the organization’s aims, the level of security awareness will rise. Every single person in the company should have a basic understanding of what security entails, which isn’t that hard to achieve. Agile and DevOps teams should have relevant knowledge about threat modeling, secure coding, and security testing tools, and they should be taught the basics of security monitoring and forensic research. People also need to be trained in how to act when an issue arises – build a good incident response program with flowcharts that everyone can use and apply. Security experts should provide active guidance and assistance within teams and actively help implement security controls and mechanisms. As the security expert, you should focus on implementing user stories properly and not discuss the user story itself, since that role is best left to the product owner.
Business teams should also start to implement defense by default and assess every situation as if a breach had just occurred. Assume bad stuff will happen at some point and see how you can minimize the damage from each point of view. Do this on all levels; disable local admin accounts, use application protection frameworks, implement key management, apply network segmentation everywhere, use coding frameworks, patch all the time, test everything, monitor everything, and start analyzing your external and internal network traffic. The ultimate goal is to make it as difficult as possible for pen-testers and hackers. It should take them weeks, months or even years to get somewhere.
Possibly the most interesting role for security officers in Agile worlds is that of the security evangelist. The evangelist acts as a domain expert across all teams and behaves as a team coach so that teams become more aware of issues such as best practices, regulations, tooling, and intelligence. They discuss security and privacy-related topics, thus increasing awareness and skills across the teams. As the security expert, you should be easily accessible to teams so make sure you are where you’re most needed. Make sure people know where you are located, show yourself at stand-ups, and be a part of sprint retrospectives that involve security features. If a physical presence is difficult to achieve, at least make sure that there is a way for quick remote interaction. Be present on communication channels like Slack or Mattermost. If such platforms are not being used, at least maintain a dedicated mailbox for security questions and prioritize these requests over everything else.
We, the InfoSec industry, are facing a future in which change is a constant factor and we must develop a way to deal with that. To be successful, we must understand and acknowledge that we can no longer do it all on our own. Unless we start to behave as a member of the business development team, we will fail horribly and become sitting ducks. Acknowledge the fact that—for the most part—security is not rocket science, and much can be achieved with good old common sense.