As the drum cries start to beat about a possible Russian
invasion into the Ukraine, many of our own Federal Agencies are also warning
the American public about possible Cyberattacks originating from Russia.
So far, as I peruse the news headlines on a daily basis, I
have not seen concrete stories to this effect.
But, it does not mean that something has not actually happened. I would say that there is a good chance something
could have happened, but for obvious reasons, it does not want to get reported.
But anyways, all of this yet once underscores the need for
not just Corporate America, but the average American folk to be proactive about
their levels of Cyber Hygiene. No need to
repat them here, a simple Google search can tell all that you need to know.
But keep in mind that maintaining good Cybersecurity practices
is not just about protecting your digital assets. It also means making sure that any backdoors or
vulnerabilities that exist in your Software Development Lifecycle (SDLC) are
fully addressed and remediated.
This is a topic I have covered on occasions before, and in
fact, I have an eBook on Amazon just dedicated to this.
So it all comes down to this one common denominator: Security is still not yet a high priority for
software development teams. It call comes
down to two things: 1) Software developers are in such a time crunch for the
deliverable that they simply lose oversight of the importance of checking for
security gaps and vulnerabilities, or 2) A lot of the software development work
is outsourced somewhere else, where the Quality Assurance (QA) standards are
substandard.
So apart from what I have said in the past, here are some
other tips that your software development team can implement as well:
1)
Decrease the attack surface:
Today, many businesses those of the
MSPs, are now relying upon just one software-based mechanism in order to reach out hundreds if not thousands
of people. This is yet once again best
exemplified by the Solar Winds attack.
The Cyberattacking group deployed a piece of malicious code into one package
called the “Orion”. This is a tool that
was used to push software updates and patches to all of the clients from just
one source point. Because of everybody
had access to it, this malware spread to literally thousands of clients, and as
a result, they became infected. In technical terms, these are known as “Supply
Chain Attacks”. Despite the security
weaknesses this poses, unfortunately, many MSPs and their associated software
development teams are choosing to go this route, for the sheer sake of
convenience. Btu what can be done to
help the mitigate risks here? If you are
insistent of just having one point at which to deliver all of your updates and firmware
in one simultaneous spread, then make sure that tool has been thoroughly tested,
and continues to be so for any security vulnerabilities that can crop up. This is what happened in Solar Winds
attack. The Orion package had many weaknesses
and holes, it was never tested. Or even
a more bullet proof way to handle this is store all of your upgrades and patches
in one central place, and then notify your clients that they are available for download. That way, they can deploy them on their own,
and you have basically cut out the risks that are involved with simultaneous based
implementations.
2)
Create a Bill of Materials:
Ok, this is a term that is probably
used quite a bit a bit in the manufacturing industry. This simply means that you are keeping an
inventory of all of the inputs that are being used to create a product. The same concept can apply here to the software
development world as well. Obviously, the inputs are going to be quite
different, as they will primarily be software modules that your team has
developed. But whatever the task is, they
need to b accounted for, and whether or not they have been security tested, and
have made their way to the QA process for other checks that are needed. This is also known technically as the “SBOM”,
and in fact, this is now mandatory per the Cyber Executive signed by
Biden. There are frameworks out there
that you can use to help you build out your SBOM, and one that I see seriously recommend
is available through the OWASP project.
More information about this can be seen here at this link:
3)
Deploy the Zero Trust Framework:
This is probably one of the most beaten-up
terms in Cybersecurity. Essentially, this
means that you are getting rid of the Perimeter Security approach, and instead,
breaking out your IT and Network Infrastructure into different zones, and each
one of them requiring at least three different layers of authentication that
the end user must go through. Well, this
same concept should be equally applied to the SDLC world as well. So, if a software developer wants to gain
access to a particular software module, he or she will also have to go through
at least three or more layers of authentication. In the end, they are no different than your
or I, and they should not be given any levels of implicit trust, as the name of
this Framework dictates.
My Thoughts On This:
The Cyberattacker of today is realizing that many IT
Security teams are simply too focused upon the protection of digital assets. Therefore, they are now going into areas of
penetration where security is not so much of a focus, and one of them is the SDLC
world. They know that a lot of stuff
goes untested, especially when it comes to open-source APIs.
But you know what?
Your software development team needs to be held to the same, if not
higher levels, of Cyber Hygiene that regular employees are required to abide
by. After all, they are the ones that know all of the inner workings of not only
your apps, but those are designed and delivered to your clients as well.
If they wanted, they quite easily flip the switch, and
launch a rather covert, and quick insider attack if they wanted to.
Sounds scary? Well it
does. Now is the time to take proactive
measures and higher levels of accountability of your software development team.
No comments:
Post a Comment