According to Gartner, Inc. overall worldwide IT spending is projected to total $3.8 trillion in 2019 while at the same time worldwide spending on information security products and services will reach more than $124 billion, an increase of 8.7 percent from 2018. Those are pretty mind-boggling numbers but then again still only approximately 3.3 percent of IT spending is security related. Also in a recently performed survey by Gartner eighty-eight percent of global CIOs have deployed or plan to deploy cyber security software and other technology in the next 12 months.
Needless to say that IT related security is a very hot topic as data has become arguably the most valuable commodity around. But still IT security is viewed by many (especially software developers) as a necessary evil defined in some annoying security guidelines.
In almost all projects I’ve been involved in, security has been architected into the environment very late in the game – akin to building a bricks and mortar bank and worrying about security aspects when the building is already complete. Or to put it into a simplified development life cycle – compile it, deploy it then let the firewall and some network segmentation take care of the rest (and of course cross your fingers that nothing ever bad happens to your data).
Security starts with the Specifications
Even though the concepts of Abuse Cases, Threat Modeling, etc. have been around for ages (like in 1970’s/1980’s) they are very seldom applied to modern day software development. Instead of focusing only on the functional aspect of the specifications (for sure features are more fun to build and allow the developer to show off his talent) it’s just as important in today’s age of cyber threats to focus on security specifications.
For example if questions like “Where are my high-value assets?”, “Where am I most vulnerable to attack?”, “What/Who are the most relevant threats?” and “Is there an attack vector that might go unnoticed?” are considered very early in the development process then the resulting system will be much more robust to potential attacks and not just be reliant on a firewall to protect it (I have nothing against firewalls btw).
While the features of the MVP are being debated and sketched out the above mentioned security specifications should also be well thought of, documented and clearly understood. Data breaches have been known to kill new products before they properly were able to hit the market.
Embrace the Security Guys early
So instead of viewing the guys from the security department as the necessary evil mentioned above – embrace them in the development life cycle very early on – like from the beginning. Doing the first penetration test a couple of months after releasing a product just to obtain this fuzzy feeling of being secure is not a bad idea but for sure not the best one. The earlier your developers are confronted with security threats and advice the more robust the resulting system will become.
Also in todays world of speed, speed and more speed where new features are king you can still not afford to leave your systems and data exposed and vulnerable to the ubiquity of cyber threats.
(c) 2019 – Reto Kaeser, Managing Partner @ astarios