An Overview of the Security Ecosystem in Programming

Matthew SetterOctober 18th, 2017Last Updated: October 18th, 2017

0 27 6 minutes read

As is the case in recent years, security breaches are becoming ever more accepted. Just take the recent Equifax breach as an epic example. No matter where we look, it seems like someone is always falling victim to some form of malicious attack or another.

While the recent breach is fresh in our minds, I wanted to take a moment to get an overview of the security ecosystem, concerning software development. I’ll go over some of the key things you can do, from a constructive and active perspective, to improve the robustness of your applications against security breaches.

To do that, I’m going to look at four key areas. They will primarily discuss specific technical steps. However, they’ll also discuss employee and user mindsets. These four are not exhaustive because I’m attempting to cut a broad swathe across the possibilities open to us, keeping in mind that everyone’s situation is different. With that, let’s begin.

Know the OWASP Top 10

One of the essential tools in developing ever-more secure software is staying abreast of the OWASP Top 10.

If you’re not familiar with it, it’s a constantly updated list of the top ten most severe vulnerabilities affecting software applications. The list is compiled based on research across a range of software languages, industries, and countries.

The current list includes attack vectors that you’d likely expect, such as injection attacks, broken authentication, session mismanagement, Cross-Site Scripting (XSS) attacks, and broken access control. But it also includes a number that you might not expect, including security misconfiguration and under-protected APIs (which is a new addition in 2017).

Each vulnerability is documented in depth, as well as how to determine the level of exposure to the threat and what can be done to protect against it. I strongly encourage all developers, no matter their level of skill and experience, to get to know the OWASP Top 10 and stay up to date with it.

Perform Security Audits

The next step is to consider including software security audits as part of your continuous development (CD) process.

A security audit assesses and measures an application’s readiness against security threats, such as those in the OWASP Top 10. However, they also include talking with staff, looking at access control configurations, and assessing physical access to systems.

Some of these steps can be automated, such as security scans. However, some of them have to be performed manually, such as talking with staff. Regardless, by performing a comprehensive security audit, you then have a baseline from which you can prepare a plan of action for continuously improving the quality of your application.

I’ll finish up this section by focusing on security scans. There are both open- and closed-source options available. A good example, one that I’m more familiar with, is RIPS (Re-Inforce PHP Security).

RIPS automates detection of security vulnerabilities in PHP-based software and can detect vulnerabilities based on industry-standard lists, including the OWASP Top 10, CWE, SANS 25, and PCI-DSS.

Tools like this can:

be integrated into existing software development pipelines, able to be run with every code change
help with prioritizing bugs
help with the education of developers about where the bug came from
assist in improving overall quality standards

You can find a range of security scanners in the Related Links section.

!Sign up for a free Codeship Account

Restrict Access to Information

While we can validate and sanitize input, perform security audits, and consider code complexity, it’s also essential to ensure that processes, users, and programs are only able to access what they should.

So next, let’s look at controlling information access within our applications or implementing the principle of least privilege. When applied, the principle ensures that

every module (such as a process, a user, or a program, depending on the subject) must only be able to access the information and resources that are necessary for its legitimate purpose.

Take a patient medical service as an acutely pertinent example. If said service accurately displays a user’s medical history over a given period but doesn’t check if the records requested belong to the currently logged in user, then any patient can see any other’s records. This situation is a disaster just waiting to happen.

Implementing this kind control, however, in most languages, isn’t that difficult. Most languages have packages that implement the two leading standards for information access restriction: Access Control Lists (ACL) and Role Based Access Control (RBAC) mechanisms.

If you’re not familiar with one or both, here’s a quick overview. An ACL

specifies which users or system processes are granted access to objects, as well as what operations are allowed on given objects.

Whereas RBAC:

is an approach to restricting system access to authorized users. It [RBAC] is a policy-neutral access control mechanism defined around roles and privileges. The components of RBAC such as role-permissions, user-role, and role-role relationships make it simple to perform user assignments.

It’s beyond the scope of this article to look at either in depth. However, I’ve included links to further documentation on both standards, as well as to language implementations of them.

Understand Your Code’s Wider Ecosystem

In addition to looking at the code, we need to consider the environment within which it sits and the other services with which it interacts.

As a software developer some years ago, my standing with my boss (a veteran UNIX/Linux systems administrator) rose considerably when I expressed interest in gaining the LPI certification.

If you’re not familiar with it, the LPI certification is a series of certifications around the Linux operating system. However, there are many other options, such as RHCE and Microsoft-related certifications.

The individual certification is not especially important. What was important for my boss was that I was keen to understand the larger ecosystem in which my code ran — a quality sorely lacking at the time.

By doing so, he suggested, I would look at the code that I was writing in an entirely new way. Instead of seeing it in isolation, believing that the boundaries of my responsibilities stopped at the edges of my code, I’d consider the implications of what I was writing more holistically.

And he was correct. By doing so, the OWASP Top 10 that we considered at the start of this article takes on much more meaning. One easy example is better appreciating the impact of SQL injection attacks on the database you’re using, and what you can do to limit its impact.

So encourage your developers to learn about the entire ecosystem or tool chain. What versions are you using and what are the weaknesses and the known security vulnerabilities of each service that you’re using? What workarounds need to be applied? Are there alternative options that can be used, that don’t have as critical or as many vulnerabilities?

Encourage a Security Mindset

Now that we’ve covered the secure software development ecosystem through a range of technical, quantitative ways, I want to finish up by looking at the more human side of the equation.

Specifically, I encourage you to nurture a secure software development mindset both within your organization and among your customers and users.

The motivation for that is encouraging developers to have a security mindset as a fundamental aspect of their software development skill set. By doing so, they will be continually looking for security flaws when writing software. By nurturing it in your users, you’ll help them avoid falling victim to attacks.

Security expert Bruce Schneier said it best in a post on the topic when he said:

If more people had a security mindset, services that compromise privacy wouldn’t have such a sizable market share. Laptops wouldn’t be lost with millions of unencrypted social security numbers on them, and we’d all learn a lot fewer security lessons the hard way.

However, while it’s easy to talk about, it’s not as easy to teach. However, there are courses available that teach a security mindset. If you’re keen to start today, here’s a final suggestion from Bruce:

Anyone can exercise [their] security mindset simply by trying to look at the world from an attacker’s perspective. If I wanted to evade this particular security device, how would I do it? Could I follow the letter of this law but get around the spirit? If the person who wrote this advertisement, essay, article or television documentary were unscrupulous, what could [they] have done? And then how can I protect myself from these attacks?

In Conclusion

We’ve now considered four broad aspects of the current secure software development ecosystem. These four cover both the technical, as well as the human, side of the equation.

From the discussion of these four areas, I hope that you’re now in a better position to learn how prepared your applications are based on such standards as CWE and SANS 25, as well as to see security from a holistic perspective.

There’s so much to this topic that a single article can never discuss it in its entirety. However, I hope that this will be but the beginning of a journey into software security, one that helps us both be better prepared to handle current and future security threats.

Links

Published on Java Code Geeks with permission by Matthew Setter, partner at our JCG program. See the original article here: An Overview of the Security Ecosystem in Programming

Opinions expressed by Java Code Geeks contributors are their own.