[BreachExchange] An Overview of the Security Ecosystem in Programming

[Audrey McNeil]

https://www.javacodegeeks.com/2017/10/overview-security-
ecosystem-programming.html

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riskbasedsecurity.com/pipermail/breachexchange/attachments/20171019/cc4b2ccb/attachment.html>