Appsec is challenging but not impossible
Computing gathered UK cybersecurity and infrastructure leaders together to examine the extent of appsec challenges and discuss different approaches to risk.
There can be little doubt that application security is being squeezed in the enterprise. Infrastructure and organisations themselves have grown more complex, developers are under commercial pressure to deliver faster, cloud development skills are hotly contested and agility is seemingly the greatest imperative - until it isn't. In the event of a breach the recriminations start flying and the obvious questions are asked.
"Why was something insecure pushed into production? Why wasn't code secured before?"
Ways to avoid this scenario were the topics of discussion at a Computing roundtable, sponsored by Checkmarx held last week in the city. The roundtable was held under Chatham House rules, so names and organisations have been withheld, but the panel included leaders from the financial, housing and manufacturing sectors. Despite being from different industries, one thing delegates had in common was that they all represented large, complex and in most cases heavily regulated organisations.
The conversation kicked off with an exploration of some of the challenges that delegates were experiencing when trying to reconcile the objectives of agility of app development and the need for security and compliance.
Straight away the conversation zeroed in on the importance of culture. One delegate commented:
"There will invariably be tension between those who feel that security is a problem that needs to be moved out of the way, and those who feel it's essential for the health of the business but doesn't need to be an obstacle, and that partly comes down to culture and language.
"Developers think that security is a problem because they arrive there too late. They're desperately trying to get something into production, security are asking if they've done this, this and this and the answer is generally 'no.' Therefore security tell them they can't go into production. The challenge I have is trying to explain to developers that engaging early and throughout shouldn't slow them down. If anything it should speed things up. Why would you want to push something insecure into production? You're going to have to fix it at some point so why not do it sooner rather than later?"
Another cultural, organisational issue was raised by a CIO, who considered some of the risks of outsourcing culture.
"What we don't do well in house we have come to reply on other companies to do that for us. I don't know what's in that box. I don't know what's in that code. I'm buying on faith, trust and reputation.
"My worry is the lack of framework. There's money to be made in agile development and showing value to the business. But the value doesn't take into account the fact that it has to be risk managed and we don't seem to have a common perspective on how to address that risk."
In order to begin mitigating some of the risks that businesses face from their application code, it's helpful to try to work out how much is coming from the increasingly complex infrastructure stack. A Head of Architecture considered this point:
"We're zeroing in on code but I think it's the constituent parts of the whole ecosystem presenting challenges. We've adopted a hybrid approach which means we not only have to worry about our on-prem security posture but also our cloud providers. Then throw SaaS into the mix as well. I feel the problem has grown exponentially if I'm being honest."
Trust - but not too much
Underlining the cultural challenges facing appsec, and cybersecurity more widely, was the observation from this IT Security Manager that humans remained his biggest problem.
"Security is such a rapidly moving target so to expect devs to be up to date with security feels unrealistic. It's hard for them to keep up to date with their own stuff. I think the way forward is some sort of guardrail automation to remove the human bottleneck."
Certainly automation is helpful in companies where you don't necessarily have the resource to employ lots of security architects, and where your reliance on third parties for certain functions creates vulnerability.
There was a good deal of talk about the extent to which third parties in the software development chain could and should be trusted. Recent events have illustrated with brutal clarity the operational and reputational damage that can be inflicted via third-party code.
A good deal comes down to trust, and there was a consensus in the room that an organisation, particularly when it works with a large number of contractors and third parties has very limited visibility up the development chain and therefore the organisation has to trust by default. However, that trust needs to be backed up with some sort of enforcement although as someone else pointed out, that isn't foolproof.
"It's quite easy to massage some of these questionnaires to to meet necessary criteria. Realistically if you have hundreds of suppliers how are you going to make sure they're all telling you the truth? "
Another pointed out that if these surveys are seen as check box, gate opening exercises they can engender a false sense of security. Third-party security work is incredibly important but it takes specialists to do it - and most organisations don't employ them.
The conversation concluded with consensus that it wasn't realistic to think that software development could be made risk free, and that different organisations had different tolerances. However, automation and appsec by design are sensible and accessible ways to try to mitigate some of the risks so well examined during the discussion.
