Who Owns Security?

When we think about security in the framework of our applications, you may be wondering whose responsibility is it ultimately to ensure applications are secure, is it the developer, security professional or is it the operations team?  A 2020 survey done by Gitlab may have surprising results to that question.   The report found that most operations professionals lacked faith in a code developers’ ability to write secure code, and most developers felt they lack proper guidance around security. Not surprisingly, the study found confusion amongst the respondents as to who actually owns security in the organization.  While 33% thought the Security organization did, 21% gave the responsibility to developers, and 12% to operations, and the remaining 29% thought everyone owned security.

Everyone Should Own Security

While the 29% that thought everyone should own security is encouraging, ideally that number should be larger.  Because in reality everyone should be responsible for security, and feel they have a responsibility for security in their organization.  The Gitlab survey also examines the “Shift Left” phenomenon (moving security emphasis earlier in the development process) happening at organizations, and concludes that organizations are embracing a “Shift Left” culture, and getting security into code earlier in the development cycle, but this move has been slow, and less than complete. Gitlab pointed to a couple of examples of this, including the result that only 13% of organizations provided developers with the results of their DAST (Dynamic Application Security Test) scans, and few organizations increased security scans during the development phase.

Security During Development

If you look at how most organizations decide who and where application security should reside today, there’s two places where security is typically emphasized.  First there’s pre-production/development, and during this phase, the ownership of security is firmly in the developer’s hands.  Ideally, the developer should be planning and thinking about coding with security during the development of the application.  During development that also means including testing cycles for security, including SAST (Static Application Security Testing) and DAST (Dynamic Application Security Testing).  Unfortunately, here developers have been less than successful at finding vulnerabilities before they make it to production, with the highest number of vulnerabilities discovered and reported in 2020.

Security During Production

The second area organizations should be focusing on security for applications is during production or runtime of the application.  The owners here are both the operations and security teams, along with developers when needed.  In the past that has meant security in two places.  First the network perimeter, and the use of a web application firewall (WAF), along with the security on the server the application is running on.  Most organizations continue to rely on standard anti-virus or Endpoint Detection and Response (EDR) solutions (solutions that are designed for end-user systems, rather than servers) to protect their servers.

Unfortunately for organizations, neither of these areas of security focus have been successful at fending off attacks, especially zero day attacks in recent years.  Combined with the increased vulnerabilities making it to production discussed earlier,  for organizations, including development, security and operations teams, it is time to rethink the way the organization approaches application security, both during development and in production.

NIST on Application Security

The release of a new NIST SP800-53 Revision 5 Security and Privacy Framework is a good indication that things need to change and gives us insight as to what the next generation of application security is going to look like.

The latest revision of NIST SP800-53 includes the requirement of RASP (Runtime Application Self-Protection) and IAST (Interactive Application Security Testing). It’s a first in recognizing these two advancements in application security by now requiring them as part of the security framework, and adding new technologies to the development and to the production phases of application deployment, give development, operations and security teams new tools in their cyber security battle.

Where RASP Fits Into Application Security

RASP as a product category has existed since 2012, and came about because of the need for security that is specific to the challenges and threats that web applications face.  If you are thinking the WAF is fulfilling all the application security requirements, you would not be alone, but you would be missing out on many application security needs.  While WAFs have been around in their current form since around 2002, WAFs function as a network perimeter security solution and they have failed to meet the security needs around many of the issues that applications face in today’s threat landscape.  A typical RASP solution has code level visibility into the application and can analyze all the activity related to the application to accurately identify when an attack occurs, thereby reducing the amount of false positives.  Unlike WAFs which only see the traffic coming to and from the server, a RASP can see what’s happening inside the application, to determine if there’s inappropriate use of the application itself.  In addition, RASP is really the first security category to offer self protection for the application.

By running on same server as the application, RASP solutions provide continuous security for the application during runtime.  For example, as mentioned earlier, a RASP solution has complete visibility into the application, so a RASP solution can analyze an application’s execution to validate the execution of the code, and can understand the context of the application’s interactions.

RASP solutions do require operations and security teams work together, which may be a challenge for some organizations where these functions are siloed.  Implement RASP will help drive the requirement that everyone is responsible for security in the organization.

IAST As Part of Application Security

IAST is the other new recommendation for application security coming from the NIST revised draft, and if you haven’t heard of IAST, there’s a good definition available from Optiv:

“IAST is an emerging application security testing approach which combines elements of both of its more established siblings in SAST (Static Application Security Testing) and DAST (Dynamic Application Security Testing).  IAST instruments the application binary which can enable both DAST-like confirmation of exploit success and SAST-like coverage of the application code. In some cases, IAST allows security testing as part of general application testing process which provides significant benefits to DevOps approaches. IAST holds the potential to drive tests with fewer false positives/negatives and higher speed than SAST and DAST.”

With these two new requirements (RASP and IAST) for application security being added to the NIST framework, it’s really time to rethink who in your organization is responsible for security and how you implement application security.

K2 Cyber Security Can Help With Application Security

Here at K2 Cyber Security, we’d like to help out with your RASP and IAST requirements.  K2 offers an ideal runtime protection security solution that detects true zero-day attacks, while at the same time generates the least false positives and alerts.  Rather than rely on technologies like signatures, heuristics, fuzzy logic, machine learning or AI, we use a deterministic approach to detect true zero-day attacks, without being limited to detecting attacks based on prior attack knowledge.  Deterministic security uses application execution validation, and verifies the API calls are functioning the way the code intended.  There is no use of any prior knowledge about an attack or the underlying vulnerability, which gives our approach the true ability to detect new zero-day attacks. Our technology has 8 patents granted/pending, and has no false alerts.

K2’s technology can also be used with DAST testing tools to provide IAST results during penetration and vulnerability testing.  We’ve also recently published a video, The Need for Deterministic Security.  The video explains why the technologies used in today’s security tools, including web application firewalls (WAFs) fail to prevent zero day attacks and how deterministic security fills the need for detecting zero day attacks.  The video covers why technologies like artificial intelligence, machine learning, heuristics, fuzzy logic, pattern and signature matching fail to detect true zero day attacks, giving very specific examples of attacks where these technologies work, and where  they fail to detect an attack.

The video also explains why deterministic security works against true zero day attacks and how K2 uses deterministic security.  Watch the video now.

Change how you protect your applications, include RASP and check out K2’s application workload security.

Find out more about K2 today by requesting a demo, or get your free trial.

 

s