Too many Projects are leaving Security (Penetration Testing) until the last minute and this is making your company vulnerable to outside hacking and delaying deadlines.
Security is a big topic nowadays and it is finally getting some traction at the top table of many companies. There have even been cases of the CEO and the CIO being fired for security breaches. And I don’t mean little companies with small losses either. Target, yes Target (https://www.target.com/), was the object of a sophisticated hack that ended up costing the company at a minimum One Hundred Million Dollars. The CIO did have a strong security background but that was not enough to ensure the safety of the company data.
How the hackers got in was through social engineering but what they did after they were in should have been prevented by thorough security reviews of their software.
Whether or not the security reviews were up to par or not I’ll leave that up to you but there is a lesson in this for us all. Security can no longer be the last thing we think about in our businesses.
How Software Development Usually Works and Why it’s So BAD for Security
What usually happens in software development projects (especially larger ones) is that the software product goes through a very long development cycle which culminates in a high-pressure last couple of months where everything is jammed into the time left before the dreaded deadline. That deadline having absolutely no bearing on the company profitability, it’s just a deadline someone promised someone more important than them it would be delivered by.
You can’t effectively security test unstable software
Keep in mind, until you have a stable release you cannot reliably security test because the big changes coming in behind (or during) your security testing are going to basically negate all the hard work you have done security testing.
So, Your Developers work crazy hours, testing functionality timeframes are squeezed into what the developers leave available all in a rush to meet the promised deadline.
Then once user testing is done, the rush to fix all bugs is complete and then it’s time for security testing. The problem is, ALL THE TIME IS GONE!!! That promised deadline, it’s this weekend and there is no time left to book in the security consultants, no time left to do the security testing and certainly no time left to fix those security holes!
So you put the software live, the capital for the project closes out and before you know it, everyone has forgotten about security testing the software. That is until you get a breach like Target had!
Unfortunately, what you end up with is a ticking time bomb, just waiting for someone smart enough to take advantage of you.
This kind of development pattern is typical of both waterfall projects and badly run “agile” projects we will from now on refer to as “Fragile”.
Why Agile for Big Software Projects?.
I’ll say it up front so we are on the same page. Though I’m not an Agile Zealot, experience has taught that the best way to bring security into a large software project is to do it through Agile. (not Fragile).
The reason for this is down to a couple of reasons.
1. Every sprint should be producing products or features
2. Every sprint should feed up into a product release
3. Product releases early and often create early ROI
A product release is just a release that is either time or feature bound. I am going to work with time-bound releases because it fits within this method better.
If you are new to agile (or would like to know what I mean by agile) I’d recommend taking fifteen minutes of your time to view this introduction video on youtube then come back here to finish reading: https://www.youtube.com/watch?v=502ILHjX9EE
As my purpose here is not to teach agile but to give you a method for producing secure software I going to assume you are now familiar with the agile approach.
How to make Security so much better in your software development lifecycle by using Agile
There are four key things I expect every large agile project to have in place in order to give yourself the best possible chance of success. These are as follows:
1. Make sure Agile is understood by the business (sprints are time and cost bound but scope variable)
2. Use a five-tier architecture. Dev, QA, Pre Prod, Sec_Prod, Prod. Dev is where your developers play. QA is where functional end to end testing happens. Pre-Prod is for user acceptance testing, Performance Testing, Sec_Prod is for Security Testing (This is so security testing can be ringfenced as they require stable source code). Prod is your full production system. You can drop back to a four or three tier architecture post project if you want once the pace of development has dropped off.
3. Sprints Deliver products or features. They do not work towards all project features at once.
4. A release is a time-bound bundle of features and products that previous sprints have produced. The release is moved from QA into Pre-Prod for user acceptance testing.
There is a logic worked into the above because if you have releases built into a time-bound cycle you can then start to work with security consultants to thoroughly test every release. This allows you to book in these highly skilled and in-demand resources ahead of time because you know when you will need them next.
You will also now be able to give the security consultants your full release notes including test scripts, source code access and documentation.
Say for example we have a 12-month project where releases are planned to go through to production every three months. Assuming you are running two-week sprints for your software development and every sprint produces working products or features you could be running a cycle like this:
1. Two Sprints, release to QA (four weeks)
2. Functional Test / Regression Test for one week, bug fix for one sprint (two weeks), retest bugs (one week).
3. UAT in Pre Prod, one week (send bugs back to Dev)
4. Performance testing one week (send bugs back to Dev)
5. Migrate to Sec_Prod and Security Test one week (Send bugs back to Dev)
6. Complete security bug fixes (urgent priority), regression test functionality affected as it passes through systems. retest security bugs (one week)
7. Release to production (provided sign off is achieved)
8. Alter above timeframes to suit your business as you learn how your team operates best.
Now you have a product delivery cycle you can work efficiently with.
This gives you a 3-month cycle you can work to that puts security testing in last in the cycle which is where you want it to be because by then your code will be stable and that releases code base is as complete as possible. Now you can rinse and repeat right up until the project is complete. Of course what this means is that you are security testing every effective two sprints which means that your real rollout schedule is every month after the first 3 months of development. If you follow the five-tier architecture model you can wait until you have six sprints accumulated before you test and release to production, the frequency is up to you but the model and method are what gives you the ability to manage this effectively.
This works so much better in Agile because waterfall does not give you the ability to complete releases of working functionality in this manner. The reason is that waterfall projects typically concentrate on delivering all functionality in one big bang, not multiple releases. We know the first agile release is likely to be messy as everyone learns how to work together on the project but that can be worked through and in the end, you will end up with a better result.
Saving up all security testing until the last minute means exposing your company to significant risk and jeopardises your go-live dates as security defects delay deployment into production.
By using a mode of working where time and cost are fixed and scope is the variable it allows you to have predictable release schedules where security testing can be embedded into the process.
By creating a five-tier architecture you can segregate your security testing and use it as the final stage gate to production release.
You can use a four-tier architecture but you will slow up the release cycles due to security testing requiring a stable code base.
A three-tier architecture does not support strategic security testing in large projects.
No project is going to go exactly to plan but if you can work through the project issues and stick as close as you can to the plan you will find that you deliver a secure, working solution.