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
No comments:
Post a Comment