In our global, digital world, data is king – and malicious attackers are on a constant lookout for ways to conquer the throne. With a rapidly changing business landscape,the old, reactive approaches to security are no longer enough – if they ever were. Effective application security leaders are changing their tactics to keep up with the transformations.
It shouldn’t take a security incident to make an organization pay attention to securing the applications and other areas that are so important to the business. With our ever-increasing reliance on data and the applications that carry it – and hackers ever-growing capabilities in causing more and deeper damage – this truth will only ever become more accurate.
Breaches, most notably the big name hacks that occurred over the past year, are costly. They cost in lost time, wasted efforts, reputation, customer losses and, of course, untold financial setbacks.
It’s time to settle this: Security IS a business enabler. The concept of mapping security initiatives to business objectives is still a somewhat novel idea, but it’s catching on.
Over the past few months, we’ve been hosting round-table discussions with CISO thought leaders around the world, in conjunction with the fantastic Information Security Media Group (ISMG). The meetings in Singapore, New York, and L.A. were centered on sharing ideas and concerns about the implementation of Application Security. Each discussion was lively, with participants comforted in sharing pain points and offering solutions. They also shared some fantastic insights on what is working well for each.
Now is the time to repair the problem of disconnect and tension between security and the rest of the company to truly make the case for security as a business enabler. It’s time for the rest of the company to truly make the case for security as a business enabler.
Those leading forward-thinking organizations in their information security efforts understand the changing landscape and increasing importance of proactive and security and risk awareness. And their successes have come partially because they’ve been able to communicate this well to the leadership.
So without further ado, we thought we would share the most significant insights of the participants on how to ingrain security within the organization:
Benjamin Franklin once said: “An ounce of prevention equals a pound of cure.” That is the exact message we need to be communicating with our organizational leadership, and finding the right way to do so is the first step in championing security as a business enabler. The round-tables theme was ‘Application Security: How to Make Security a Business Enabler’ and many ideas were shared for how to make that a reality.
With the slew of recent big name breaches, organizations are finally starting to wake up to the fact that security threats have the capacity to cause major damage, as illustrated in Ponemon’s recent survey on the Mega Breaches of 2014. While disconcerting that it takes a multi-million dollar hit and customer, and reputation losses to get the message through, it’s better late than never. Some of the participants believed that a major outage is what it would take to get their leadership to listen more carefully. The general consensus, however, was that it’s a matter of communicating the issues in the context of business. Overall, business leaders have begun working more closely with the security team, participants agreed, though in varying degrees of cooperation.
All the application security leaders we met with agreed that security needs to be better integrated into business practices and procedures, and agreed that metrics are key to showing your programs ROI. “If you can’t measure, you can’t improve,” one of the attendees said. The attendees discussed which KPIs in particular need to be measured and communicated back to the leadership in data that means something to them, like the length of time it takes to fix vulnerabilities in business critical applications after discovery, the ratio of security flaws to performance bugs, and the business-based risk diminished through application security practices.
The AppSec leaders also discussed the struggle of speeding the organization up by creating a strong security program, as opposed to slowing it down by making processes more difficult. Part of that problem is that in the past, security was seen as an extra, bolted on to the organization. But in aligning information and application security and business objectives and developing a long-term plan, security pros are ensuring the continuity of the business while securing it from the inside out. Security can no longer rest on the laurels of the IT department or the security team: if it’s going to be effective, security needs to be embedded throughout the organization and championed by the Board.
Participants consistently said that building security in with a secure SDLC (Secure Development Life Cycle) is the ultimate goal and the key to ridding businesses of the old way of looking at security. The organizations represented in these meetings were each at various points in their maturity levels regarding a secure SDLC, however, indicating that there is still much to be done in this area.
There is a definite shift in where the responsibility for security lies, and we’re seeing more of an emphasis on seeing security as a critical business function. By matching operational security risks with business objectives, participants agreed, we’re well on our way in showing how security fits into the business on the whole. Participants of the round-table have been focusing more on communicating the business value of protecting business-critical data and securing the organizations’ applications, conveying the integral message that security is not just an IT issue. “Taking ownership at all levels is important to prevent new form of threats,” one of the attendees stated.
When it came to the participant’s pain points, the frustration caused by the separation between the security team and developers was the most palpable. The communication gap between them is typically in major part due to an embattled approach from both sides. Developers have historically seen security people as interfering with their code, slowing them down, and only communicating in levels of disappointment. And the security team has historically looked upon developers as careless towards security with a focus only in getting things done ASAP.
A few attendees pointed that the business has to articulate clearly to the developers in terms of the programs needs and not to overlook the security aspect. “Projects today are driven too much by schedule, and not by quality,” one participant said. Developers need to be given time to do the quality check with scalability features to create new patches for a more secure future.
The issue isn’t so much about the developer’s skill pool, participants said, but rather how the developers are approached with their security duties, and how the security team builds and maintains credibility with them. With the implementation, or at least early stages, of a Secure SDLC in forward-thinking organizations, security awareness and the need for writing and designing more secure code is definitely there, but how much it’s felt in the organization depends on how developers are approached with it.
For so long, developers have just been expected to produce viable, bug-free code in the shortest amount of time as possible, but the threat landscape has changed. These days, even the most banal security bugs can be much more detrimental to an organization. Adding code of “the basic ingredients like input validation or error handling…can easily stop many of the attacks today,” one of the Application Security leaders added.
The Application Security pros we met with shared a variety of the methods they’re using to get developers more engaged and less frustrated with writing secure code. It starts with a strong understanding of the development team’s needs and current tools to be able to find ways to integrate security more fitting to what the developers know and love. Next, participants said, the goal is to create an open channel between the developers and the security team or manager. One of the best ways to do this is to find a security champion that understands why security is crucial to the business and how it fits into his work. At that point, you have your foot in the developer’s door, and further steps towards engaging the team with security will be more fruitful.
A CISO at one organization shared that they had started a security incentive program to both attract new talent and reward current employees by offering rewards to those who implement and show strong, secure coding practices. Other ideas tossed around included hosting OWASP or Application Security related events with an eye towards developers.
At Etsy, for example, head of security Rich Smith has begun the simple tradition of keeping a jar of candy on his desk. The candy helps in luring developers to come for the candy and stay for any questions or concerns they might have. Rich’s team also picks up the beer tab after the security events he facilitates for them, making the after-work events less of a task and more of an extracurricular activity. More fun, less burden – that’s one of the easiest ways to help developers engage more with security.
This paper shows some other great ways to get developers more engaged with security.
Another common thread we heard in the meetings was that having the right tools for your specific environment is highly important. But more important is knowing how to best use the tools for your needs, and how to get your teams to use them correctly.
The application security leaders we met with view this as a critical part of a secure SDLC, and goes far in proving the ROI of your security program. Working smart is so much more efficient than working hard, and by finding the correct set of tools for your specific program, you’ll be working smarter.
Participants spoke about the importance of having a set of tools that, when deployed correctly, will discover applications and databases, determine if they are vulnerable to external or internal attack, monitor them for an attack and for misuse, and finally protect critical data at rest. They don’t use every tool on the market; rather, effective security pros will test and choose only the tools that work best for them – and their teams.
In the conversations, participants spoke about the decision processes they go through in choosing the best tools for the job. Many have chosen to opt for monitoring and scanning solutions that can help gain greater visibility at the application layer, and those whose results can be easily understood by developers, QA teams, and others working on building business applications. The ultimate solution, we heard, would be a toolbox that together reduces test time, response time, integrates well into the development environment, and offers reports that are easily deciphered by every stakeholder.
One of our participants noted the complexity of some of the tools, commenting that you “need to have a PhD for some of these [solutions].” Tools too intricate to understand or those that don’t offer enough initial training and setup will mostly likely end up as shelf-ware, burning through budget and driving down ROI royally. This is where the importance of automation came into discussion in one of the meetings: Automating the security testing process was the key factor we heard in simplifying application security.
The participants also agreed that there are open source tools strong enough to do some jobs, but that many employ a mix of open source and commercial tools for full coverage. The key, the leaders agreed, is choosing tools that have been known to integrate well with other tools. This is where the KPIs mentioned earlier fit in: Being able to measure the effectiveness of your tools and communicating that in the context of your programs ROI will go a long way with executives, participants said.
Learn more about choosing the right tools for your defender’s toolbox.
The general consensus was that another key component to communicating the value of a security program is allowing security to seep into the board’s DNA, primarily by having security people on the board. The top-down approach is what has been working for many of the application security leaders we met with, and is what has been earning them spots in the boardroom: Once the film is broken on getting the business on board with the necessity of a strong application security program, it’s hard for business leaders to ignore what security has to say about their activities.
This year’s Global State of Information Security survey conducted by PwC found that 58% of respondents don’t feel their organizations’ Board actively participates in the overall security strategy. There remains a gap between the needs of the security team and the support they’re receiving from above. The same study, however, found that aligning the security strategy to the business’ specific needs was the second most-popular method of preventing security incidents (only behind hiring a CISO), and that the classification of business value data is the top priority in security protection programs. Both are indications of security being a more prevalent conversation in Board meetings.
The benefits to having security people in the boardroom are prevalent both during proactive security measures and during post-breach clean-up. The 2014 Ponemon Data Breach study found that when a CISO was hired either prior to or during post-breach efforts, the cost per compromised record was reduced by $10, down from $201 per record to $191.
If the Board doesn’t understand the importance of having a dynamic and robust security program, they won’t be willing to sign off on the expenses to make such a program happen. Getting security pros into the boardroom and in executive positions is what opened up doors for several of our participants to a better overall security posture for their organization.
The need to better share relevant information with all pertinent parties was another concept discussed in depth in our conversations with the security leaders. Up to this point, most organizations have traditionally worked in silos, each team working separately from the others with little to no collaboration between them.
Application security leaders present in the meetings have learned that the silo structure cannot work, especially in regards to security. Each area of an organization has its own individual security concerns, and more transparency between the security operations within an organization offers a smoother approach to securing the business.
Attendees spoke of adopting a more open approach to discussing security in the organization. Giving employees the most up-to-date information about what cyber threats are prevalent and what they should look out for on a daily basis, as well as communicating your information security policy in non-technical ways are great ways to have security be more visible throughout the company. Security awareness training is another well-established method of getting the security word out, but it’s equally important for the security teams to be aware of what’s going on in other teams, so that the nuances of each department are known to security.
Image credits: Flickr, Pixabay, Wikipedia, and Canva.com.
Sign up today & never miss an update from the Checkmarx blog
Interested in trying CxSAST on your own code? You can now use Checkmarx's solution to scan uncompiled / unbuilt source code in 18 coding and scripting languages and identify the vulnerable lines of code. CxSAST will even find the best-fix locations for you and suggest the best remediation techniques. Sign up for your FREE trial now.
Checkmarx is now offering you the opportunity to see how CxSAST identifies application-layer vulnerabilities in real-time. Our in-house security experts will run the scan and demonstrate how the solution's queries can be tweaked as per your specific needs and requirements. Fill in your details and we'll schedule a FREE live demo with you.