A Potentially Fragile Security Bargain With API Secrets

Tie a metaphorical string to your digital transformation and give it a yank. It could be a string or you may need a rope depending on how far you've transformed.  Its girth determined by the volume, value, and sensitivity of the underlying data.

Either way, APIs are probably attached to the far end. Way out there close to where users and partners are. Mobile apps, third parties, whatever, and wherever you’ve got data and information to share via APIs.

The strength of the line represented in strength of the security bargain upheld with your API secrets.

An App Security Secret For A Speedy CI/CD World

There is an unspoken secret in the devops world that impacts every application security team.

A startup with a singularly focused product and a few related value streams likely has a very different idea of continuous delivery and devops than a organization that delivers more complex and varying types of value streams that all have to integrate into a core devops process. 

Securing the startup in the above example means planning for the expectation that any committed code can be released to customers at any time. This makes sense because the number of sub-systems that comprise a startup’s system is often small. Any single defect can be easily shipped and either rolled back or quickly fixed without much risk of regression as there generally aren’t a large number of dependencies involved. 

Since startups drive much of the behavior in the application development space, there is an assumption that large, complex applications can be delivered the same way. 

Can complex apps be delivered more quickly with continuous delivery? Certainly.  

That said, the more complex the application is, the more in-depth the various subsystems will need to be integration tested so that we know that they work with each other and manage risk. When speed is paramount, even fully automated testing takes time and most organizations simply aren’t there yet. Unit testing and smoke testing isn’t sufficient even if updates can be shipped quickly particularly when potential regulated information is involved such as personal information, credit card data, etc. on a publicly facing internet application.

If French doors were an organization’s product, unit tests would pass if each door opens separately but significant rework might be required if both doors can’t be opened at the same time. Now, think about the increase the complexity of testing and securing database changes holding sensitive data being made across multiple value streams in a continuous way. That’s just one of N aspects to be considered. 

Application security teams should be collaborating closely with test/QA teams to define common standards, agree on quality definitions, and identify the right timing for various types of testing. The timing will vary greatly depending on the tool, approaches, and level of automation within an organization. 

Good rule of thumb:  Ensure that you are modeling your security methodology based on CI/CD and devops practices of organizations that are building apps with a level of complexity at least equal to yours.  

The fewer dependencies and potential regulatory issues within the value streams delivering an application, the closer to code complete an application can be delivered in a continuous way.  That may not be the hottest startup that delivers dozens of times per day.

The speed of continuous delivery is relative to the alternative methods in which software can be delivered.

There certainly are organizations that have scaled good processes used in startup apps and securely scaled them into larger, more complex applications. There may also be individual components of a large, complex application that can be served well with a very fast continuous deployment model. But an organization likely won’t be successful if they just begin general deployment of continuous updates to an existing internet facing application without significant definition, integration standards, planning, and testing if they want  a stable, high performing, secure application. 

There is a secret opportunity for cyber security teams in the chaos of devops. 

Not-so-secret greatness can be the result. 

Follow me on Twitter for discussion and the latest blog updates: @Opinionatedsec1. Or, start your own discussion using #crazygoodcyberteams on twitter or Linkedin and I'll read it.

SEE ALSO

Responsibility And Accountability in Cyber Security 

Rarely Discussed Real Life Application Security Decisions

Cattle Versus Pets In Securing DevOps Pipelines

Rarely Discussed Real Life Application Security Decisions

The cyber security industry often frames application security as a singular entity with a similar model, approach, and employee requirements across the full range of organizations. 

If only that were correct.

A key difference among application security models and approaches isn't the toolsets involved or the level of automation of those tools in the build pipeline, it's where the analysis of defects found by those tools takes place. The differences in each approach or model drive requirements for skillsets, resources, and scope with potential impacts outside of the cyber security team.  

Your organization will have some fundamental decisions to make. 

In some models, the development team performs the analysis of app security defects. The app security engineers tend to be tool focused. The output is simply passed to the development team. Application security engineers only need to have some familiarity with OWASP and other app security vulnerabilities as the analysis, prioritization, and severity of the defects is performed by the dev team.  The downside of this model is that (1) the dev team will need to be resourced to handle this analysis and (2) in many organizations, it’s the devs that have to process through the inevitable false positives and duplicates. 

In other models, an outsourced vendor performs the analysis of app security defects. They may also run the tools. From interviews, I’ve learned that some with the title, “application security engineer” actually represent the organization to manage the app security vendors. The downside here is (1) the potential cost of buy vs. build and (2) the organization may not be building longer term expertise, knowledge, and historical data around application security. 

In still other models, the application engineers perform the analysis of the defects. The upside of this model is that the app security team provides tangible value identifying false positives, removing duplicates, and often validating the automated classifications provided by the scanning tools. The downside is the depth of specific application development knowledge and experience required of the app security engineers.  In my team’s case, we focus on hiring previous developers and automated test engineers as we’ve rarely interviewed security engineers that have the ability to perform such tasks at a high level. 

So, when you are doing comparison between programs or listening to other senior cyber describe their application security program, there may be variances that don’t necessarily fit your organization’s goals, budget, or ability to resource. Some organizations can do great with a high percentage of app security interns because the work and the costs of detailed defect review are likely being borne elsewhere.  

You’ll also need to dig in during interviews to determine the fit of candidates. The title of “Application Security Engineer” can mean many things from “I throw the switch on tools” to “I manage a vendor” to “I look at defects and analyze them”. 

One size does not fit all in application security. As they say, “all models are wrong but some are useful.”

Hopefully, you find these useful. 

Follow me on Twitter for discussion and the latest blog updates: @Opinionatedsec1. Or, start your own discussion using #crazygoodcyberteams on twitter or Linkedin and I'll read it.

SEE ALSO

Conference Capture The Flag (CTF) for CISOs? 

Cattle Versus Pets In Securing DevOps Pipelines 

An Application Security Program Is More Than Scanning

Cattle Versus Pets In Securing DevOps Pipelines

Securing a devops pipeline can often be regarded as a special cyber security use case.

The thinking behind the specialness of that use case is that security within the development pipeline is so important that securing devops warrants having its own process. We even see security sometimes included in the name, devsecops. 

But devops is a business process. 

Just one of N key and critical business processes in the enterprise.

Although securing devops pipelines requires some specialized dev and build process knowledge, devops is simply one part of a security ecosystem that shares similar needs and requirements with a lot of other complex and sensitive business processes that also need to be secured. 

Common needs. Common process.

Identity and access.

Unauthorized sensitive data exposure.

Activity anomalies.

Compensating controls.

So, the security program methodology and process needs to transcend devops and escale across all business processes in the enterprise in a standardized way.  Like cattle, in herds.

Standards development.

Governance during execution

Common metrics.

If security programs maintain a very boutique approach for devops and have to establish different processes for the rest of the enterprise, the program won't scale. Each secured process will need individual attention very similar to pets.

Cattle versus pets. 

The additional work in developing scalable approaches is worth the time and resource savings.

Your program. Your scale.Your results.

Follow me on Twitter for discussion and the latest blog updates: @Opinionatedsec1. Or, start your own discussion using #crazygoodcyberteams on twitter or Linkedin and I'll read it.

SEE ALSO

The Only Constant In Cyber Security

An Application Security Program Is More Than Scanning

An Application Security Defect Misunderstanding

An Application Security Program Is More Than Scanning

Just like vulnerability management is larger than just patching, application security is larger than just scanning applications. We can’t confuse performing a group of application security activities with having a application security program. 

If execs don’t understand the connection of the program to their business objectives, then you don’t have a “program”.  You have activities. Activities that aren’t likely sufficiently understood, connected, or compelling to have the level of funding that is needed to cover the requirements of securing your key applications. 

An Application Security Defect Misunderstanding

Functional software defects and security defects aren’t different.

Both born from developers. Found with automated tools. Neither achieving a standard. 

Same remediation process. 

Yet, treated differently. In process. In perception. 

The Application Security Thought Process

I’m a believer in specialists.

Why? I know the principles behind flight but I couldn’t build an airplane, how internal combustion engines work but bring cars to mechanics, and share the same key board as prize winning novelists but couldn’t write one.

Specialists know something deeper than the tools and basic principles for their craft.

The difference that makes the difference in the value of the end product. 

MOVED: The Application Security Novelty

This post has been moved to https://medium.com/@opinionatedsec/making-application-security-more-than-a-novelty-3aa1c0cf8420?sk=cae3b4ea0341dfe884a2cfc043290483

Follow me on Twitter for casual conversation and the latest blog updates: @Opinionatedsec1 

SEE ALSO

The Five Pillars of a Successful Application Security Program 

A Cyber Security Metaphor 

Why Operations Engineers Don't Always Transition Into Effective Cyber Security Practitioners

The Five Pillars of a Successful Application Security Program

You've been given task to build out or improve an application security team. Congratulations. You now have a key question to answer: "how will your application security efforts help your organization balance application delivery with application security?" Will you have an answer?

Maybe you are lucky and can slowly work towards an answer to this question since your company has just decided to build out an application development team or, like me in my current role, the answer is a bit more complex since you've moved to an organization in which application development has been going on for years but never has been really governed from a security perspective. Vendors can help but they really are focuse on their own tools.

This post will try to provide you with some considerations for building or improving your application security from something other than a vendor perspective. I draw a lot from my own experience in the field. My journey to becoming a security practioner included some stops leading large high visibility commercial application development teams building API platforms and products for hundreds of millions of users. You've likely used some of the products. Simply by the nature of our product and the frequency with which every appsec defect was reported in the news demanded formalizing an application security program long before appsec was really something defined. Since then, I've defined and implemented a number of application security programs at a number of different organizations.

A key learning from my experience is that there is no "one size fits all" solution to application security. Each organization brings its own unique goals, risk appetite, and requirements. Your organization will need to plan accordingly.