DevOps and SecOps Together

By now, you probably have seen the depiction of the horizontal figure eight with the words Dev and Ops in each loop followed by arrows representing the software delivery life cycle (SDLC). You might also notice the word security, outside of that circle.

Culturally, this representation isn't far from actual. Many security operational teams would admit that they lack security visibility into the workload prior to the release and operate phase of the SDLC. This is simply a byproduct of integration, or lack of, between both sides both technical and non-technical.

The buzz behind the term "DevSecOps" continues to evolve and much of the demand continues to motivate security operational teams to integrate within the SDLC by way of process and technologies without impact to time or duration for releasing an application or revision to a workload.

Light at the end of the tunnel

Security tools used throughout SDLC isn't new. The idea of vulnerability scanning is prevalent in multiple areas such as:

• IDE
• Code repo
• Dependency checks
• Static and Dynamic checks
• Hashing artifacts
• Runtime security
• and...much....much...more!

What is new, is bringing into DevOps, security checks often utilized during "only" operational state, or in order words, once the application is deployed into production.

Network security vendors are beginning to test out platforms that can be brought into the build process as demonstrated with F5's WAF tester.

This is not meant to be an advertisement for F5, but to raise awareness around the effort security vendors are making to "Shift Left" as referenced in the buzz phrase.

Making the shift

The WAF-Tester, though still in testing, seems to be F5's effort to provide pass or fail data against common web application attacks. They indicate support of testing specifically:

"Node.js"
"PHP"
"MongoDb"
"Microsoft Windows"
"Unix/Linux"
"XML"
"Java Servlets/JSP"
"ASP.NET"
"Python"

There is a prerequisite for which the install runs on Python 2.7+.

Once installed, an initial configuration file must be created to link the target application server with the BIP-IP WAF.

* Key notes:

• Running f5-waf-tester --init must navigate to local.bin folder.
• The application server (pre-deployment) must have connectivity to the BIG-IP WAF.

Once the test is complete by running f5-waf-tester, the output gets saved under the current folder as "report.json".

Reviewing the output it indicates "fail" or "pass".

pass = false - The attack was not block by the WAF

pass = true - The attack was blocked by the WAF

There are foreseen limitations, such as unreachability of operational subnets during the testing phase, but would create the opportunity for both DevOps and Security to work together. Testing also seems limited to known policies created within the WAF, but the pass "fails" would create and understanding of what signatures need to be enabled in the production environment.

In summary, the goal of reducing vulnerabilities to the application prior to release is common. This represents an effort to achieve visibility during the development phase that gives security operations data that "they" can do something about it, without placing the burden on the development teams. Where both groups are seeking opportunities to integrate sooner, I would say this is a great start!