Last updated at Tue, 14 May 2019 19:34:01 GMT
Last month, New York State’s Department of Financial Services (DFS) published final of 23 NYCRR 500, dealing with financial institutions and cyber security. Essentially, saying that financial services organizations will be required to have best practices-based cybersecurity programs. This, at face value, is exactly what you’d expect – and applaud. Many of the affected organizations are leading edge – defining those best practices, so there won’t be too much outcry from them. What is interesting, however, is some of the areas the rules cover – specifically the set of requirements around application security programs.
Now, I might argue that the DFS’ interpretation of appsec is narrow (exclusive focus on developing secure code, with some mention of pen tests), but the fact that it’s there is great. It’s an acknowledgment that web app attacks are the top breach vector. It draws attention to the fact that any cyber security program must have an application security component, which is a good sign that regulators and non-security professionals are starting to take the time to develop a better understanding of what’s needed. It does raise the question – is it complete? what is missing?
We have seen this movie before (when PCI came out with, and then evolved the Data Security Standard) – making some parts of security required and raising the minimum bar for all. The interesting opportunity for DFS is that they only require 2 of the 3 pieces we see in organizations with strong application security programs. There are 3 big pieces we see in organizations building strong application security programs.
3 Key Components to a Comprehensive AppSec Program
1. Developing secure applications
2. Monitoring and protecting apps in production
3. Periodic, but regular penetration testing
Now, there are a variety of ways companies break this up (Gartner, for example, published this excellent note about infusing security throughout the application lifecycle in March 2017 – which delves into much finer resolution). We’re talking about a similar set of capabilities – scan, test, and harden prior to deployment, monitor and protect in production, and test periodically. Each of these has a different focus, a different set of associated activities, and a different toolset. Here is an overview of application security programs based on the conversations we’ve had with customers.
Develop Secure Apps
Infusing security into the web app development lifecycle is a formal effort that has been underway for more than a decade. From our conversations, many organizations view this as a long-term project. Some struggle to make this effective as it requires strong collaboration with developers and their cooperation – when developers are typically motivated by speed/time-to-market and innovation, not security. Typically, security teams use application security testing (AST) tools at various points during development, test, and deployment to identify vulnerabilities – which then must be remediated by developers. Obviously, this capability has been heavily impacted by the change in development organization and process brought about by agile and DevOps.
Monitor and Protect Apps
When applications moved through the development process slowly, multiple test points and reviews meant a high degree of confidence in the security of the code. With applications being developed and deployed at a higher rate, many organizations are focusing a lot more on monitoring and protecting applications in production than they used to. Traditionally, the only way to secure apps in production was with a web app firewall (WAF) – which most organizations grapple with from a tuning and noise perspective – and faster deployment of applications exacerbates that issue. This is where tCell can help – enabling both greater visibility (hence faster remediation) and higher confidence (fewer false alarms) by virtue of our architecture. Here’s some more information about our approach to application immunity.
Penetration Test Apps
Periodically, organizations have to test. We’ve seen everything from internal teams to dedicated external teams, to automated tests, to crowdsourced efforts – in different combinations and various intervals. Testing is great, and sometimes the only way to find the gaps between components and controls, as well as misconfigurations and errors. Tools come from both open source and commercial sources.
Again, this is sourced from a bunch of conversations with customers and prospective customers – perhaps a self-selecting bunch, but it points to good momentum. From a high level, the progress we’ve made on application security as an industry is impressive – we have a good and improving understanding at a regulatory level (e.g., 23 NYCRR 500, PCI DSS), some very mature programs in enterprises leading the way, and have incorporated some important developments (agile, DevOps, cloud) along the way.
Sorry for the long post, but this is really important. Thanks for reading!