Physically Detached Yet Academically Attached

Week 14 Software Security Practices

Lesson Title Software Security Practices
Perform a security audit of the code of an existing system,
Learning Outcome(s) identify problems that violate best security coding practices
and make recommendations to fix each problem.

At SJPIICD, I Matter!
LEARNING INTENT!
Terms to Ponder

Software Design Pattern a description or template for how to solve

a problem that can be used in many different situations.

Interaction is a kind of action that occurs as two or more objects

have an effect upon one another. The idea of a two-way effect is
essential in the concept of interaction, as opposed to a one-
way causal effect

Best Practice a standard way of complying with legal or ethical

requirements.

Object-oriented design Patterns that imply mutable state may be

unsuited for functional programming languages.

Essential Content

Software Security Best Practices

Software security isn’t simply plug-and-play.

It’s never a good security strategy to buy the latest security

tool and call it a day. Software security isn’t plug-and-play. You
need to invest in multiple tools along with focused developer
training and tool customization and integration before you’ll see a
return on your security investment.

x Patch your software and systems

o Many attackers exploit known vulnerabilities associated
with old or out-of-date software. To thwart common
attacks, ensure that all your systems have up-to-date
 Physically Detached Yet Academically Attached

patches. Regular patching is one of the most effective

software security practices.
o Of course, you can’t keep your software up to date if you
don’t know what you’re using. Today, an average of
70%—and often more than 90%—of the software
components in applications are open source. You need to
maintain an inventory, or a software bill of
materials (BOM), of those components. A BOM helps you
make sure you are meeting the licensing obligations of
those components and staying on top of patches.

x Educate and Train Users

o Employee training should be a part of your organization’s
security DNA. Having a well-organized and well-
maintained security training curriculum for your
employees will go a long way in protecting your data and
assets. Include awareness training for all employees
and secure coding training for developers. Do it regularly,
not just once a year.

o conduct simulations like phishing tests to help

employees spot and shut down social engineering
attacks.

x Automate routine tasks

o Attackers use automation to detect open ports, security
misconfigurations, and so on. So you can’t defend your
systems using only manual techniques. Instead,
automate day-to-day security tasks, such as analyzing
firewall changes and device security configurations.
Automating frequent tasks allows your security staff to
focus on more strategic security initiatives.
o You can also automate much of your software testing if
you have the right tools. That includes, as noted in No. 1,
maintaining a software BOM to help you update open
source software components and comply with their
licenses. With an SCA tool, you can automate a task that
you simply can’t do manually.

x Enforce Least Privilege

o Ensure that users and systems have the minimum
access privileges required to perform their job functions.
Enforcing the principle of least privilege significantly
reduces your attack surface by eliminating unnecessary
access rights, which can cause a variety of compromises.
 Physically Detached Yet Academically Attached

o That includes avoiding “privilege creep,” which happens

when administrators don’t revoke access to systems or
resources an employee no longer needs. Privilege creep
can occur when an employee moves to a new role, adopts
new processes, leaves the organization, or should have
received only temporary or lower-level access in the first
place.

x Create a robust IR plan

o No matter how much you adhere to software security
best practices, you’ll always face the possibility of a
breach. But if you prepare, you can stop attackers from
achieving their mission even if they do breach your
systems. Have a solid incident response (IR) plan in place
to detect an attack and then limit the damage from it.

x Document your security policies

o Maintain a knowledge repository that includes
comprehensively documented software security policies.
Security policies allow your employees, including network
administrators, security staff, and so on, to understand
what activities you’re performing and why.

o Also, it’s not enough just to have policies. Make sure

everybody reads them. At a minimum, make that part of
the onboarding process for new employees.

x Segment your network

o Segment your network is an application of the principle
of least privilege. Proper network segmentation limits the
movement of attackers. Identify where your critical data
is stored, and use appropriate security controls to limit
the traffic to and from those network segments.

x Integrate security into your SDLC

o Integrate software security activities into your
organization’s software development life cycle (SDLC)
from start to finish. Those activities should include
architecture risk analysis, static, dynamic, and
interactive application security testing, SCA, and pen
testing. Building security into your SDLC does require
time and effort at first. But fixing vulnerabilities early in
the SDLC is vastly cheaper and much faster than waiting
until the end. Ultimately, it reduces your exposure to
security risks.
 Physically Detached Yet Academically Attached

x Track Your Assets

o You can’t protect what you don’t know you have.

o Do you know which servers you are using for specific

functions or apps? Which open source components are in
your various web apps?

o Don’t think tracking your assets is that important? Just

ask Equifax, which was hit with a $700 million fine for
their failure to protect the data of over 145 million
customers, how important it is to remember which
software is running in which application. The credit
rating agency suffered the breach after they failed to
patch the vulnerable Apache Struts open source
component in one of their customer web portals. Equifax
claimed they weren’t aware the vulnerable open source
component was being used in the customer portal.

o Keeping track of your assets now saves headaches and

disasters later down the line. This process should be
automated as much as possible since it can feel like a
Sisyphean task as organizations continue to scale their
development.

o In addition to tracking your assets, take the time to

classify them, noting which ones are critical to your
business functions and which are of lower importance.
This comes in handy later for your threat assessment
and remediation strategy.

x Perform a Threat Assessment

o Once you have a list of what needs protecting, you can
begin to figure out what your threats are and how to
mitigate them.

o What are the paths that hackers could use to breach

your application? Do you have existing security measures
in place to detect or prevent an attack? Are more or
different tools needed?

o These are just some of the questions you need to answer

as part of your threat assessment. However, you also
need to be realistic about expectations for how secure
you can be. This means that even if you take the
maximum level of protection available, nothing is ever
unhackable. You also need to be honest about what kind
 Physically Detached Yet Academically Attached

o of measures you think your team can maintain in the

long run. Pushing for too much can lead to your security
standards and practices being ignored. Remember that
security is a marathon, not a sprint.

o In judging your risk, use the basic formula:

o Risk = Probability of Attack x Impact of Attack.

o Another way to think about risk is how likely something

is to happen versus how bad it would be if it did.
Chances are pretty low that a whale would drop out of
the sky and crush you, though it would be catastrophic if
it did. Alternatively, getting bitten by a mosquito while on
a hike is pretty likely, yet not likely to cause significant
harm beyond a few itchy bumps.

x Stay on Top of Your Patching

o Are you patching your operating systems with the latest
versions? What about third-party software? Chances are
you’re lagging behind, which means you’re exposed.
o Patching your software with updates either from
commercial vendors or the open source community is one
of the most important steps you can take to ensure the
security of your software. When a vulnerability is
responsibly discovered and reported to the owners of the
product or project, the vulnerability is then published on
security advisories and databases like WhiteSource
Vulnerability Database for public consumption. Ideally, a
fix is created and pushed out before the publication,
giving users the chance to secure their software.

x Manage Your Containers

o Containers have grown in popularity over the past few
years as more organizations embrace the technology
for its flexibility, which makes it easier to build, test,
and deploy across various environments throughout
the SDLC.
o To secure your container usage throughout the CI/CD
pipeline, you should run automated scans for
proprietary and open source vulnerabilities from start
to finish, including in your registries.
o Along with these scans, application security best
practices for working with containers also include
important steps like signing your own images with
 o Physically Detached Yet Academically Attached
o

o tools like Docker Content Trust if you are using

Docker Hub or Shared Access Signature if your team
is on Microsoft’s Azure

x Prioritize your remediation Ops

o Vulnerabilities have been on the rise in recent years,
and this trend shows no sign of letting up anytime
soon. Developers have their dance cards full when it
comes to remediation. Given the scale of the task at
hand, prioritization is essential for teams that hope to
keep their applications secure while maintaining their
sanity.
o Doing so requires performing a threat assessment based
on the severity of a vulnerability (CVSS rating), how
critical the impacted application is to your operations,
and a variety of other factors. When it comes to open
source vulnerabilities, you need to know whether your
proprietary code is actually using the vulnerable
functionality in the open source component. If the
vulnerable component’s functionality is not receiving
calls from your product, then it is ineffective and not a
high risk even if its CVSS rating is critical

x Encrypt, Encrypt, Encrypt

o This one has been on the OWASP Top 10 for years,
making encryption of your data at rest and in transit a
must-have on any application security best practices
list.
o Failure to properly lock down your traffic can lead to
the exposure of sensitive data through man-in-the-
middle attacks and other forms of intrusion. If, for
example, you are storing user IDs and passwords or
other types of info that could put your customers at
risk in plain text, then you are putting them at risk.
o Your basic checklist encryption should include making
sure you are using SSL with an up to date certificate.

HTTPS has become the standard these days, so do not

be left behind. Hashing is also a good idea.

x Manage Privileges
o Not everyone in your organization needs to have access
to everything. Application security best practices, as
well as guidance from network security, limit access to
applications and data to only those who need it.
 Physically Detached Yet Academically Attached

o The reason here is two fold. First, if a hacker is able to

gain access to a system using someone from
marketing’s credentials, you need to prevent the
hacker from roaming into other more sensitive data,
such as finance or legal. Second is the concern over
insider threats, whether unintentional -- losing a
laptop or attaching the wrong file to an email -- or
malicious. By managing privileges and adhering to the
Principle of Least Privilege of giving employees access
to only the data they need, you could reduce your
exposure compared with having no controls in place.

x Embrace Automation for your Vulnerability Management

o In recent years, developers have taken more ownership
of the security of their applications, especially when it
comes to tasks like vulnerability management. As
security shifts left, developer teams are testing early
and often, pushing as many of their security checks to
the beginning stages of their development when
vulnerabilities are easier and less costly to fix. Given
the sheer numbers of vulnerabilities, developers need
automated tools to help them manage the unwieldy
testing process.
o For testing proprietary code during development, static
application security testing (SAST) and dynamic
application security testing (DAST) can help to find
potential vulnerabilities in your code. While SAST and
DAST play an important role in closing security holes,
proprietary code is a relatively small portion of your
overall codebase.

o Open source components generally comprise between

60-80% of your codebase in more than 92% of modern
applications. This means securing open source
components should be a top priority for your
application security checklist. Software composition
analysis (SCA) tools can help teams to run automated
security checks and reporting throughout the SDLC,
identifying all of the open source components in their
environment and detecting which ones have known
vulnerabilities that put your applications at risk.

x Penetration Testing
o While automated tools help you to catch the vast
majority of security issues before a release, no
application security best practices list would be
 Physically Detached Yet Academically Attached

complete without citing the need for pen testing. Pen

testers can comb through your code, poking and
prodding your app to find weak points. Good pen
testers know exactly what a determined hacker will try
when breaking into your application.

o You can hire professional hacking firms or use

freelancers who work with bug bounty programs like
HackerOne and BugCrowd who seek out
vulnerabilities on their own for cash prizes. If you are
not already sponsoring a bug bounty for your product,
you should be.

o Despite the extra expenses of working with pen testers,

you are far better off paying for white hats to try and
break in rather than face the consequences of a breach
in the wild.

x Be Careful with Tokens

o This should be an easy one to secure, but it is
surprising how many developers don’t properly secure
their tokens for third-party services
o Unfortunately, you can easily find unsecured tokens
online by searching through popular developer
websites. Developers simply include the token details
in their open source repos instead of storing them
somewhere more secure

SELF-SUPPORT: You can click the URL Search Indicator below to help you further understand the lessons.
Search Indicator
https://resources.whitesourcesoftware.com/blog-whitesource/application-security-
best-practices
https://www.synopsys.com/blogs/software-security/top-10-software-security-best-
practices/