The Stack Is the Application

When working with clients, I see a variety of environments and an even wider variety of configurations. In today’s world, adopting the whole stack is not just a good idea, I’d say it’s a requirement.

What do I mean by the whole stack? Many developers accept a few roles when it comes to their application:

• Writing the code
• Deploying the code
• Maintaining the code

However, this approach, which is followed by many companies today, is riddled with security problems that put clients at risk. It’s an overly simplistic view of any modern application — and that lack of vision will cost companies down the road.

Common Assessment Reveals

On every application security assessment we perform there are configuration issues. Often these vulnerabilities are due to faulty configurations. A couple of common issues are servers not being hardened and patched or development that doesn’t include simple header inclusions that help protect user information. While injection and sanitization issues are high value (and rightly so), issues like these show cracks in the implementation that includes DevOps.

When we do an internal assessment, we find that the persistence tier and the servers themselves are often under protected. Security engineers often take control of every aspect of the build environment during an internal security assessment. With developers having admin or near-admin rights on source code repositories, build machines and production servers, a compromise of their systems means a compromise of those devices. Indeed, as supply chain vulnerabilities affecting software end users become a more common occurrence, CDW believes that the lack of security on these pieces will increase the amount of legitimate software being distributed with malware or other dangerous code signed by the company. In all respects, the application will seem safe but, in fact, it will not be.

Securing the Stack

So how can a company protect itself. DevSecOps might be one solution to look at. Security will have to respond at the speed of DevOps. But we contend that all parties should look at the application and all its pieces, the whole stack. Gone are the days when security for the application server was left to someone else. Gone are the days when the security of the database was left solely up to the database administrator (DBA). Here are seven actions companies can take to secure the stack.

1. Training.

Make sure all developers know about the Open Web Application Security Project (OWASP). For web applications this includes the Top 10. OWASP is working on a mobile device part as well.

Accept that the Top 10 isn’t where you stop. There are several vulnerabilities that aren’t represented in the Top 10.

2. Network Segmentation

Network segmentation is a critical portion of any security implementation. This helps mitigate the compromise of a system on the network. Most clients we work with have a flat network (security-wise). When we compromise a single device on that network we compromise a significant portion of all devices on that network. That is why internal access with malware is highly prized. Why should a compromise of a marketing laptop compromise your applications SQL Server when marketing has no need to access the SQL Server? When thinking about segmentation and application security think about:

• The persistence tiers: Very few people need direct access to the database. Some may use reporting tools, developers and DBAs may need to change data. These are all fine business rules and should be granted, but they should be documented.
• The build process machines: Very few need direct access to these machines. Document those who do and block all other access.
• Developer and operations machines as they pertain to the application: As above, very few people need direct access to these machines and that access should be limited.
• The source code repositories.

3. Review the Data in the Application

During assessments, many companies are shocked to find the level of information being stored in the applications. This is particularly true of old applications, those that have been around and built upon for a while. Asking “Why are you storing driver’s license information?” or “Why are you asking customers for social security numbers?” are questions that need to be discussed. Without bringing up credit card numbers, it goes without saying that they bring with them incredible risk. Remember, if you collect it, you are responsible for it.

4. Hardening and Configuration

Create a gold standard server. If using Docker, make sure those images are kept up to date. Seeing unpatched parts of a server is common (not to mention operating systems that are no longer supported). The lack of a hardening process or a hardening process that isn’t kept up to date is a significant risk to all organizations. Make sure that the configuration (which will change over time) is always reviewed.

5. Review Persistence Tier

Create a plan to review the persistence tier. This should be an ongoing event based on several factors like how often things change as well as the number of people who can access it. Review it for:

• The data.
• Permissions: Who has DBA rights? What rights to the application connections have been granted?
• Ask the question: If the application contains a SQL injection, what data will be compromised?
• Inter-database connections: If this database gets compromised, what connections to other databases might be used to compromise that database?

6. Put a Name on It

DevOps solves a lot of problems we have seen in the past. From experience, however, we have seen where things have failed because of a “lack of adoption” of the nonsource portion of the stack by developers.

7. Accept That the Whole Stack Is the Application

Like DevOps, this will not be easy to implement. Start small. Any piece of this can and should take time to implement correctly. The larger the application, the more difficult the implementation. Start with the persistence tier and move up the stack. Begin those conversations about data in the application.

Once an organization understands and accepts that the stack is the application and begins to approach the security around it holistically, the number of risks present will drop. Attacks and IT environments are becoming more complex. Any piece of information that is combined with other pieces of information is creating a larger risk. Getting ahead of this and looking more closely at the stack will help reduce access to your data.

Learn more about the services and solutions that CDW offers to help you secure your organization.