Application security by design
19 May 2020
Topics in this article
Application security is always DIY – and you are the SME of your own business
Your organization has unique requirements that are not only specific to your industry, its regulatory and compliance standards, but also to your overall strategy, budget, risk tolerances, partnerships, contractual obligations, and customer preferences. This means that your specific application security goals cannot and should not be dictated by any single external source of authority, be it a security standards organization, certification, analyst group, your last organization, a vendor, or any other external “list”. Adopt things that fit, reject things that don’t, and be able to explain to your customers and partners how your approach is custom designed to achieve the best possible outcomes for your interests and theirs; they will appreciate and reward you for your practicality and ownership.
Large enterprise businesses are rarely homogenous in their approach to anything, (secure) software development is not an exception. You likely have development and operations teams that utilize different technology stacks, tooling, and even divergent (software development lifecycle) SDLC methodologies. Ignore this fact at your own peril. Security teams with stagnant and rigid views of the world get worked around; Agile, adaptable teams design workable, customized solutions that continuously improve their security ease of use.
“DevSecOps” is just good ‘ole AppSec
Trying to bolt on security has never been an effective approach. Successful application security teams have known since before “Dev” and “Ops” had a head on inelastic collision that developing more secure software means being deeply involved before the first line of code is written and staying involved throughout the SDLC. Those same teams quickly learn that it is nearly impossible to develop secure software without an in-depth understanding of how software is developed in the first place. When security engineers pitch in to the up-level general software craftsmanship, opportunities are created to build trust that can turn into partnerships that foster enablement rather than enforcement.
Security maturity can never come before development maturity
Without mature software development practices in place, application security is forever mired in a game of cat and mouse, gotchas, and delays. Investment in improving overall software craftsmanship is a direct investment in the future of your ability to conduct effective and efficient release assurance as well as respond to newly discovered vulnerabilities in your software and operating environment. Contributing to this improvement and measuring its progress should be a fundamental objective and key result for any application security team, regardless of your engineering methodology’s fancy name: “DevOps”, “Agile”, “Scrum”, or “Waterfall”.
Moreover, ask your engineering team what they want to improve about their SLDC but can’t find time or resources. Lend them talent from your security engineering team to do so, not only will technology and processes improve, but relationships will be established that create a new world of opportunities to up-level your product security in the future. Having hands on experience with the product and processes they are trying to secure will provide invaluable insight to your security engineers and build trust and empathy with your engineering organization.
Hip, cool and valuable – but not a silver bullet
Application security teams have to balance risk management, release assurance, and developer enablement, often times with a larger mandate than resources, more responsibility than authority. Often risk reduction initiatives feel at odds with other business needs related to increased market competition based on the velocity of software features delivered to the end user.
The drive to increase assessment speed to mere seconds and leverage automation anywhere and everywhere are necessary responses to this reality. However, keen risk managers know that if speed and automation are not paired with other disciplines like signals intelligence and asynchronous security initiatives, critical flaws may be missed, discovered, and exploited before the organization can respond, mitigate, or remediate. Automated synchronous activities that occur as part of the SLDC are hip, cool, and valuable risk-reducing, but not risk-eliminating, activities. Reality-based perspectives on what you can and can’t do with robots, in seconds, is becoming increasingly rare.
Neglect longer cycle assessment practices like penetration tests, red vs blue exercises, and bug bounties at your own risk .
Application insecurity is a human problem. AppSec is the human solution
As technologists, engineers, and hackers we love technology. Our passion drives us to innovate, experiment, and never be satisfied with the status quo, but it is critical to remember that the concepts of risk taking, and risk management are fundamentally about biology, psychology, and economics or said another simpler way, human nature. Technological solutions to implementation, configuration, and other flaws that result in breaches have existed for decades but are consistently overlooked, ignored, or eschewed.
Humans, and therefore businesses who develop and operate software, consistently overestimate their chance of gain and underestimate their risk of ruin. Without this fundamental realization, and a plan designed to combat it, all the SAST, DAST, MAST, IAST, RASP, and an infinity of other four-letter application security technology acronyms your budget can withstand will not produce a satisfactory return on investment.
Your approach to hiring security talent will largely determine your application security outcomes
You may choose to have a large in-house team, or a smaller team focused on collaboration and co-ordination of internal and external resources, both approaches can find success. In either case, you must find talented security leadership that can design and execute a highly customized vision. They must deeply understand your business, human nature, and technology.
My advice is to focus on hiring someone who is passionate and knowledgeable in three key disciplines: software development, team development, and risk management. The one thing conspicuously missing from that list is being a “hacker”. Hiring hackers is great if you know how to utilize their skills to gain needed intelligence, but it’s hard to build better software if your security team’s entire mindset is only breaking things and finding flaws. You need a healthy balance of builders and breakers, and if you can afford them a few people who are both.
What one thing has had the most positive effect on application security in your organization?
When I ask customers, partners, and friends this question common responses include “being friends with our developers”, “fostering security champions within the engineering organization”, “providing training focused on our organization’s specific security challenges”, “being in the room when feature ideation occurs”, not once has anyone answered this question with a specific application security technology, assessment process, or even cutting edge security concept.
Years of hearing human and relationship-based responses to this question has allowed me to put application security testing technologies and services into their proper context. They are most useful whenever they give you back time to do other things. They aren’t the solution to your security problems; they allow you to automate or outsource the required “easy stuff” so that you can focus on the human aspects of designing the real solutions.
Get your copy of the 2020 NTT Global Threat Intelligence Report for more insights into the application threat landscape and recommendations from our leaders in cybersecurity.