This Trending Agile Service, May Not Serve Anyone

Services Usually Serve Teams

Could this be just another acronym in the age of the cloud, S-N-a-a-S.  Will this agile-derived “as a Service” deliver on its promise, or should you avoid it.  The answer is both, it delivers its service, yet you may be better served to escape its clutches entirely.  

Not everyone has to suffer, there are a few simple things you can do to escape with your sanity..  

  • Application Developer Teams revile the thought of it, it stops them cold, every single time. 
  • Operations Teams have fits over it, because of the delays and change-orders placed on-top of their provisioning processes.  
  • DevOps Teams watch in horror as it reverses all of their agile agility bonus points, having both fits and reviled for its very existence, being a shared function team.  
  • InfoSec Teams, charged with hardening and compliance are hit the hardest, they are forced into the service, even though every fiber of their being knows this is not the way.

Find out how to escape SNaaS forever.  Hardening, Compliance and Agile Software development can coexist with some wisdom.

Wisdom comes from stories, these stories provide a familiar sequence of events you don’t want to repeat.

In Sight Of The Finish Line

Our story begins like so many other Enterprise IT stories, full of hope, optimism, effectiveness, and business agility.  Not all of these stories end well, however. Make sure your team doesn’t end up on this path.

In our story, we are part of a company that exists in a very competitive marketplace.  We have lots of competitors, so prices are driven downwards constantly. Meanwhile our services continue to expand, and we are very good at what we do..  Our business is about delivering a service to the customer, and anything that slows or delays our service delivery, can be measured in time, effort, and eventually cost per delivered service.  We endeavor to deliver our services at a faster and faster pace, to outgrow our competitors.

To further grow our business, our new management “genius” spent months talking to customers, talking to employees and found the “holy grail” for management geniuses.  He found a single customer facing transaction, a single internal process, that takes a good portion of time to complete, but doesn’t need to take nearly that long. The work is detailed and repetitive, and a new IT application can easily produce a 400% speed increase… if we build it.  We have an opportunity to deliver an enterprise IT application that can show 400% direct savings, for every customer service delivered.

An impressive goal, to be sure.

These are the stories of which management genius legends are born.

Our management genius is furnished with a budget, resources, and told to “race to the finish-line.”  The team knows that in this project, unlike so many projects, time is actually money. Success will be easy to measure.  The earlier the solution is completed and exists in-operation, the earlier savings are realized and achieved and the more money is saved.

Our management genius enlists the latest and greatest IT solutions.  We’ll have to have the newest, most effective technology, newest languages and toolsets, newest architectures, riding the newest cloud-friendly features.  We’ll build a team fully trained in the newest agile workflows, which will develop agility to create our software solution. Our agile processes will be tuned for speed to market, with effectiveness leading over efficiencies, just as an agile project should.

As our genius team speeds to work, our software solution takes form quickly, with incremental agile milestones demonstrated weekly. Our management genius presents upstream to stakeholders regularly.  So far, we’re on-track, the functionality is shown to be exactly what will solve the slowdown. We are on-target, and moving fast.

Success seems obvious and an eventuality.  Spirits are high, our management genius starts to dream of his corner office, our genius technical leads are composing conference talks, and everyone is quite satisfied with their execution.  Success looms on the horizon for our team, life is good.

Our team completes enough agile plans, that version 1.0 is ready.  Agile processes have ensured that only the most effective features were added so far.  Everyone is anxious to realize this first dramatic change in savings.

Our next step, ist taking this software solution into production, the code works “in-development”, quality teams have signed off.  Our team simply needs to prepare our application to be production ready and get approval for deployment to production.  

We need our Enterprise IT InfoSec team to audit our application and give it their stamp of approval.  The finish-line is so close.

Our InfoSec team is an auditing body, most companies have one, by varying names.  This auditing team consists of senior level security experts, who have been “bitten” by enough security flaws, that they know what practices are best.  They ultimately provide the company with confidence that systems won’t be hacked or compromised.

We present our application to InfoSec, the auditing questions begin.  Quickly the meeting makes a hard right turn into conflict. The InfoSec team…

Says No!

Turns out, they subscribe to “Saying No As A Service”

The audit report starts to unpack the security problem, our development environments were not “hardened” correctly or confidently enough.

Our application sits on a generic OS foundation where there are all kinds of security alarms going off.  Our application was built on a normal, everyday image of the Operating System, where most services and features are left open, to help teams utilize their features.  

There are quite a few services to address, so the InfoSec team was correct.

The Service That You Can’t Argue With

Saying No as a Service is enabled in our business.  

It’s mission-critical and resilient, because of the enormous down-side risk of security flaws, and it stopped our project cold, in-its-tracks.

Our InfoSec team is the not-so-proud owner of SNaaS and our InfoSec team has the high-stress task of rejecting genius applications and genius teams quite often.  They let the air out of these high-flying projects, over and over again.

As our team addresses the audit concerns, there can be several rounds of panicked thrashing, trying to fix the problem quickly, so we can still realize the advantages of our agile choices.  Also, our time-is-money advantage is now working against us, time passes as we struggle to fulfill promises.

Round 1 is the InfoSec-run security scan of our development environment, where layers of Operating System software packages are analyzed for exploits, tools with libraries of dependencies.  Some exploits were simply unknown entirely, they existed in our environment but nobody knew they were even there. Other exploits were more difficult, they were known tools that were configured insecurely.  The InfoSec exploit scanner license doesn’t extend to our usage, so we have to engage the InfoSec team each time we need a new scan to determine status.

One of our developers is heard to have said, “But, it works on my machine”, as the echoes trail off.

Quickly Round 1 is seen to be too labor intensive, so we change direction and try Round 2.

In Round 2, our team then tries to harden an existing environment, around our application, executing hardening commands manually. They don’t understand the scope of hardening and compliance instructions and how deep it goes into the Operating System.  Our teams’ brilliant developers and engineers become very quiet as they wade, waist-high, into these sysop-style functions, and the enormous detail of configurations to be addressed, and later documented for InfoSec. Our team realizes the time needed is tremendous and starts to search for another path, Round 3.

In Round 3, our team decides to use pre-hardened images that InfoSec suggests from another foreign project team with different needs.  InfoSec audited these server images as hardened and compliant, but our application that ran successfully in development environments, does not work any longer in these new audited environments.  Our applications generate error messages not seen before, and they all point to Operating System configurations from that other project. We try several project’s audited resources, but each fails in different ways.  Round 3 offers “No Joy” and we search for Round 4

In Round 4, we now begin to try to adjust these audited server configurations to let our application work.  As we delve deeper into the weeds of system software configuration, we may have success, we may not have success.  But, with this approach, our server and application is no longer the audited compliant system we started with, as they adjust its configuration. It will have to be documented and re-audited with InfoSec.

Round 5 is recognizing that some of our coding and architectural choices were security flawed.  Some of our assumptions and dependencies that we assumed at the very beginning of the project were seriously flawed.  Refactoring our application needs to begin, this time, against a hardened, compliant environment.  

Our team then starts the search for tools to harden server images, each must pass a scan and be well documented, so when we build our application atop it, our application will also be hardened and compliant in the eyes of InfoSec.  

Finally in Round 6, an InfoSec team member recommends, which scans, hardens, verifies and documents systems for hardening and compliance.   It seems like the solution we’ve been looking for.

Next Time, Agile-Friendly, Security First with HardPrime

HardPrime performs these hardening and compliance actions to our custom needs while generating full documentation of every action taken, so we use it to build our systems for InfoSec audit.  

The project eventually successfully was put into production, and our team’s hard work did pay off, but the high-visibility of our problems were ever-present in our company, as an example of not thinking of “Security First”.Without “Security First”, our agile methodology let us down.  Agile prefers “slivers” of functionality, effectively added week-by-week.  The suggestion to begin by building a secure OS foundation, and the complexity involved, would most likely remind the stakeholders of slow-moving waterfall-style, non-agile approaches. provides a tool to adapt a Security First approach into agile processes, letting you iterate over security as simply another feature. provides an easy toolkit for InfoSec teams to eliminate Saying No as a Service.  Introducing teams to toolkits can integrate Security First into Agile processes.

Using, each project’s  underlying system configuration will be hardened and compliant to InfoSec standards, in every environment, including development.  

Even though Saying No As A Service saved the company from risk, it also delayed that application’s arrival tremendously.  Spending double to protect from catastrophic security risk is common. Using as a toolkit could have relieved that pain on all sides.

A tale, too often told, but it all could have been avoided.  The original savings realized, while keeping compliance and audit teams satisfied.  

Security First and Agile together, can eliminate Saying No as a Service. makes Security First easy.