The Beginner’s Guide to Making Sure Software is Secure

In the physical world, many people are on auto-pilot when it comes to security. They assume locking a door or arming an alarm system is enough. But in the digital world, thieves don’t get frightened away when a floodlight comes on or a dog barks. Those relentless intruders can do their work from anywhere and spend endless amounts of time hacking away in the shadows.

So how can we secure ourselves against these silent thieves?

The short answer is vigilance.

Security can’t be something you do once a year to check a box and pat yourself on the back. It’s an ongoing effort. At Leasecake, we constantly look for vulnerabilities and think about how we can build a better wall between our system and nefarious intruders who want to get inside.

If you work for a software company, I encourage you to do the same.

However, there isn’t a single, one-size-fits-all approach to software security. You’re best off implementing a multi-layer strategy combining a variety of tactics. And if you’re new to this, I can outline a good starting point.

OWASP ASVS Self Certification

• OWASP is the Open Web Application Security Project. This online community produces resources related to web application security, and it’s the de facto standard for web applications.
• ASVS is the OWASP Application Security Verification Standard (ASVS) Project. This standard provides a basis for testing web application technical security controls and provides developers with a list of requirements for secure development. 

ASVS provides a comprehensive set of elements broken down into 14 sections, each with control objectives and detailed items to achieve those objectives. Furthermore, each item is ranked against three levels of security that range from secure applications to running a business such as Leasecake to top-secret military applications.

The 14 sections are:

1. Architecture, Design and Threat Modeling Requirements
2. Authentication Verification Requirements
3. Session Management Verification Requirements
4. Access Control Verification Requirements
5. Validation, Sanitization, and Encoding Verification Requirements
6. Stored Cryptography Verification Requirements
7. Error Handling and Logging Verification Requirements
8. Data Protection Verification Requirements
9. Communications Verification Requirements
10. Malicious Code Verification Requirements
11. Business Logic Verification Requirements
12. File and Resources Verification Requirements
13. API and Web Service Verification Requirements
14. Configuration Verification Requirements

Getting Started

My wife has a shirt that has “DLF > DNF > DNS,” which means a “dead last finish” is greater than “did not finish” which is greater than “did not start.”

To me, that’s an analogy for getting started with software security. You can’t win if you’re not in the game. You have to start the process — plain and simple. Failing one or more items is not the end of the world. Failing and fixing is better than not knowing at all. By getting the first one done, it provides you with a good baseline in the future. 

Your first step is to decide which level of certification you want to pursue. There are three levels:

• Level 1 is a baseline minimum. This should be your starting point. Depending on how sensitive your data is, move up to a Level 2 assessment shortly after finishing and remediating the Level 1 assessment.
• Level 2 has additional items and controls for more sensitive data. If you have PII data, this is most likely the level you should assess. 
• Level 3 is for applications that perform high-value transactions. Banking and credit card transactions fall into this category.

I’ve given you my two cents on what the levels mean. But you should read the most recent version of the document and make an informed decision on which is most appropriate for your software. 

Once you’ve made your choice, it’s a matter of putting together a score sheet for all the applicable requirements. For Leasecake, I built a Confluence page with a table containing each requirement. Additionally, I have a column for each item that lists pass or fail and optionally an asterisk to denote if I have any footnotes. 

We also discussed, as a team, why we were doing this. Developers want to build new things, and I get it. I spent the first part of my career developing software. But we also like to sleep at night, take weekends off, and spend time with friends and family. We can’t do those things if we have an “all hands on deck” due to an attack. Getting the team involved is essential. Talk through the process, and help everyone understand that failing is not the end of the world. 

Remediation

I’d be surprised if you don’t have at least a few failures.

Don’t sweat it.

Making mistakes is human. Admitting to them and making a plan to address them is what matters.

No matter what your development methodology is, start lining up the necessary work. Once you’ve outlined the work, get estimates on the amount of time it will take and create an honest timeline.

Depending on what you find, multiple “fails” can likely go into a single story. Get all the stories into the backlog, point them, and make some decisions on how many you can do in any given sprint. From there, it’s all math.

Set reasonable goals, but adhere to those goals the same as you would a feature release. Once you’ve finished remediation, score the whole thing again, and you should come through with shining colors.

Our first pass did not expose any red flags. The items we found were easily addressable. So I created a Jira epic for the remediation items and then broke down the failures into individual stories and tasks under that epic. We had several meetings to discuss details with the developers, made our point estimates, and committed to a final remediation timeframe.

OK, Now What?

For us, the next steps were to perform penetration testing. OWASP self-certification was a great start, but any self-certification is likely to have at least some bias. It’s easy to overlook something when you are the development team. Hiring an independent penetration team makes a lot of sense, even if you aren’t legally required you should consider this a part of providing the best possible customer experience.

I’m not going to walk you through finding a qualified pen tester or who we use, but I will offer a few thoughts on what to look for. As I talked to potential vendors, my number one concern was looking for a partner. I wanted a company that I felt was looking to form a partnership with me, someone to “join my team” periodically instead of just selling me on a service right now. 

Secondly, make sure to define the process for post-remediation re-testing. I’ve worked with pen testers who wanted to nickel and dime me on remediation. Remediation is a natural part of the process you go through with pen testing. Said another way, make sure re-testing after remediation is spelled out with:

1. Timeframe to get the remediation done after the initial pen test results are in
2. Costs (if any) associated with remediation re-testing
3. Review of your remediation plan. 

When we got our report, we shared it with the engineering team and asked for their feedback. Then our principal developer wrote Jira tickets, and we estimated a time to production for the remediation. Once we had that in hand, we shared our remediation plan with the pen tester for review. This review process ensured we were managing the issues properly, so we were confident that our remediation re-test would pass.

Next for Leasecake

We are looking at software to automate and monitor governance, risk, and compliance (GRC). This will help manage risk while meeting compliance requirements like SOC 2. The right GRC software will constantly monitor and warn about changes in our environment that conflict with established policies. This type of automation gives me another tool in my arsenal, which is always welcome.