CISO, Own Your Application’s Security

Security breaches like Equifax have made it clear that security starts with executives' decisions. Learn how CISOs can positively impact their company's security strategy. 

Application ownership is a tricky thing. If once there was a single owner of an application, today everyone has a piece of the app in their responsibility. The idea of mutual responsibility is central in modern application lifecycles and provides significant advantages, such as distributed workloads and shorter release cycles. Putting technology aside, a successful DevOps Program starts with distributed ownership. But still, there are areas which trigger some difficulties for some parties in the organizations.

Application Security: In the Hands of Whom?

As a CISO, you are responsible for the company’s overall security. Some examples include the strategic design of your security systems, ensuring compliance with laws and regulations, overseeing identity access management, communicating security best practices across the organization, and the list goes on. Security responsibilities just expand with time and technological innovation. However, in most aspects, the processes have matured over the years and the CISO is the recognized owner, allowing you to define the needs and to review or evolve them when need be. That being said, there is one place where ownership is not well established yet. We seem to take it as a given that development teams own the security of the application’s code. I for one believe that developers should be able to review their own code, use common secure coding best practices and remediate bad code, however, they can’t own security. Building the processes to enable secure coding, choosing the right products to integrate seamlessly into the process, and enforcing secure coding standards is clearly the CISO’s responsibility

Just like IT owns the network and the CISO owns the network firewall, development teams own the code and the CISO should own the application’s code security.

Now that we settled who the owner should be, let’s take a look what the challenges are and how to deal with them.

Security Education and Awareness

Unfortunately, most developers have not had significant or any formal secure coding education. Developers are usually not measured by the number of vulnerabilities exposed in their code. You could add a budget entry for secure coding courses and start sending developers for external training. Putting the course costs aside, management will have to consider the impact on delivery times and absence of developers during their course(s). While you may be able to pull it off, the buy-in process would probably be long and treacherous and the outcome is usually not worth the trouble. There are more efficient and cost-effective ways to deliver secure coding education.

One thing I have learned during my career is that a hands-on approach is always more effective than theoretical lectures or videos. Providing developers with short and interactive secure coding lessons allows developers to see the impact of a vulnerability within their code. Allowing a developer to fix a vulnerability by including a code walkthrough and clear guidelines within their development environment will enhance their understanding instantly and, in most cases, ensure that this specific vulnerability won't show up again in their code.

A good place to start looking into such solutions would be Checkmark’s Code bashing platform, it offers a bunch of free lessons to share with the development champions and see how they react to it.

You Can Have Your Cake and Eat It Too

To this day, development teams are pushing back on application security solutions. Whether the problem is accuracy, speed, or just ease of use, these are all deal breakers and have become more so as Agile and DevOps practices have been adopted to introduce shorter release cycles. With delivery deadlines cut shorter and shorter, no one can accept the slow-down of the release cycle, and application security has built itself quite a reputation for doing exactly that. However, modern application security solutions have adapted to the requirements and some have actually managed to build a perfect fit for fast-paced development environments.

As a CISO, you should watch out for a few things when looking to implement application security in your organization’s SDLC.

Will Developers Use the Solution?

<!--[if !supportLists]-->·         <!--[endif]-->Make sure it works within their existing IDE (Integrated Development Environment). A developer who is asked to open and learn a separate platform to scan their code will probably do it once and forget about it the next time or just prefer not to spend time on it.

<!--[if !supportLists]-->·         <!--[endif]-->Make the code analysis as easy and immediate as possible. While most source code analysis tools can be automated to trigger a scan in the build stage, you should prefer to shift the process a bit more to the left and give the developers a chance to scan just their own code earlier, thus reducing findings at a later and more costly stage. Choose a platform that won't drive the developer nuts with dependency requirements and compliable environments. Scanning uncompilable code or even broken code provides much value by making the analysis immediate and quick. Platforms that support this functionality usually also support incremental scanning of the larger chunks of code which would allow shorter scanning cycles all along the process by scanning the deltas only, rather than wasting hours on scanning the same code over and over again.

<!--[if !supportLists]-->·         <!--[endif]-->Don't create more work than necessary. Vulnerabilities are usually part of a specific data flow within the code. Most source code analysis solutions will recognize the vulnerabilities in the code and present a long list of remediation points. In most cases, a single vulnerability is exposed along the data flow multiple times but that does not mean that they all need to be changed. Using the best fix location methodology, you can achieve up to 80% reduction in remediation efforts. Certain source code analysis solutions are able to analyse the data flow and pinpoint the fix location which would eliminate the same recurring vulnerabilities in one shot. This approach reduces remediation time and prevents developer frustration, in addition to delivering a very clear and measurable ROI.

How Much Unnecessary Noise Will This Create?

As a CISO, you definitely know how many resources go to waste on solutions that report inaccurately. Most source code analysis solutions are generic and analyse code based on a standard business logic or coding practices. This kind of approach creates an overwhelming number of false positives which in turn create confusion, frustration, and resource waste. Flexibility is key here, and as a CISO you should insist on having the ability to create your own set of flexible secure coding rules that were designed by your developers to address your needs. Defining these should be preferably done by application security experts. Done correctly and accurately, this should lead to accurate findings and little to no false detections.

Open Source Is No Different

According to Gartner, “95% of mainstream IT organizations leverage nontrivial open-source software assets within their mission-critical IT portfolios.” With this statistic, it is only natural that you treat open source no different than your own code. Open-source vulnerabilities have made headlines over the years with one of the latest ones being directly related to the Equifax breach a few months back. When looking to enrich your application security practices, you want to make sure that your application doesn't use open-source modules that could cause more harm than good. Make sure the solution you chose has built in open-source analysis capabilities and, more importantly, check how broad the offering is. If the solution supports only a couple of coding languages, you will find that it won’t cover your needs, so make sure that it is fast, accurate, and supports the different coding languages you use.

Continuously Run Application Security Behind the Scenes

You may have heard about Interactive Application Security Testing (IAST). IAST was initially introduced to help Dynamic Application Security Testing (DAST) solutions with their inherent challenges introduced by modern web and mobile application technology. IAST comes in two flavours.

<!--[if !supportLists]-->·         <!--[endif]-->Induced IAST - this type of IAST still requires a DAST solution in order to provide any value. By instrumenting the application with an agent, the DAST engine will run its attack simulation and depend on a response from IAST to validate an existing vulnerability. Think of it like knocking on a door of an empty room versus knocking on the door with someone in the room. In both cases, the action is the same but the result is different. This approach is less recommended for fast-paced CI\CD and DevOps environments as it still requires management and maintenance of a DAST and doesn’t enable full automation.

<!--[if !supportLists]-->·         <!--[endif]-->Self Sufficient (Passive) IAST - the second type of IAST is much more interesting and was actually built to overcome the caveats of induced IAST and address the challenges of application security in a fast-paced development environment. Passive IAST also requires instrumentation of the application in the testing environment, but rather than actively running dedicated tests/attacks it will leverage any form of functional testing to collect data and deliver accurate security findings in zero time. Whether tests are automatic or manual, the passive IAST will “listen in” and report continuously on any findings. Correlating IAST results with your existing source code analysis solution not only ensures application security across the whole SDLC but also ensures developers are able to act on findings immediately.

Not all applications are created equal. As a CISO, you have to ensure compliance with industry regulations. These are often a headache for the teams and specifically when they are enforced on applications which expose very little to zero risk and you should not need to spend much too many resources on them. You might want to consider offloading these to a third party to save time. Ideally, you should try to leverage the same solutions for both your heavy-risk based application security analysis and your compliance-based analysis. Check if your solution can provide a hybrid of a managed service (hosted or on-prem) to run compliance or low-risk applications by the vendor while keeping the sensitive stuff in-house and tightly integrated with the development practices. This should save a significant number of resources which can be leveraged elsewhere.

ZippyOPS Provide consulting, implementation, and management services on DevOps, DevSecOps, Cloud, Automated Ops, Microservices, Infrastructure, DataOPS, and Security

Services offered by us: https://www.zippyops.com/services

Our Products: https://www.zippyops.com/products

Our Solutions: https://www.zippyops.com/solutions

For Demo, videos check out YouTube Playlist:

https://www.youtube.com/watch?v=4FYvPooN_Tg&list=PLCJ3JpanNyCfXlHahZhYgJH9-rV6ouPro

If this seems interesting, please email us at [email protected] for a call.

Relevant Blogs:

How To Prevent Clickjacking Attacks 

A Guide to DevOps Security Checklist 

OWASP and Its 10 Vulnerabilities 

5 Tips to Keep Dockerized Apps Secure