Just recently, I wrote a whitepaper for a client on an area
of Cybersecurity of which I did not know too much about. This area is known as “DevSecOps”, and it is
simply an acronym that stands for Development, Security, and Operations. But after I got done writing it, I learned a lot
more about it than ever before.
Probably one of the biggest takeaways for me when I wrote
this piece simply underscored the fact that Cybersecurity is a team
effort. It is a giant that no one individual
can handle on their own, let alone one team.
Rather, it has to be a collaborative effort with everybody
in the company. The second thing I learned
is that there has to be a much better flow of communication between the software
development teams and IT Security.
In other words, the old days of siloed approaches and thinking
have to disappear and quickly, if we are to be successful in thwarting off
threat variants. The third key takeaway
for me is that automation is going to be a critical area here as well.
Of course, it should be used wherever and whenever it can be
reasonably, but it should mostly utilized for routine tasks, QA checking, and
even for finding any holes and vulnerabilities in the source code that is being
compiled.
This is probably the biggest area I hit upon in the content: The need for greater security in the code. For example, software developers have been
left alone in the blame of Cybersecurity.
Traditionally, this has always fallen on the laps on the CISO and the IT
Security team.
But this can no longer be the case. As I have said, everybody has a responsibility
to protect the digital assets of their company, and yes, even the software
development teams that you hire.
This one of the biggest focal points now for DevSecOps: How to create and compile much more secure
source code and streamlining the checking processes that are involved. So, it is no longer the software developer that
will be responsible team, it will also fall onto the hands of the IT Security and
Operations teams as well.
The thinking here is that having two extra pairs of eyes
will make sure that the Web application that is created either for internal or
external uses will be the most secure ever.
But it is important to keep in mind that developing secure source code
also involves making use of what is known as APIs.
These are essentially open-source libraries that are
typically deployed between the front and back ends of any web application that
is being created.
These APIs typically consist of lines of code that can be modified,
edited, revised, reused, etc. over and over again. The main advantage of this is that the
software developer does not have to write code from scratch, thus saving time
and money, especially for the client.
But the problem here is that these API libraries often come
from software-based community forums which have not tested them, or have not upgraded
with the latest patches and upgrades.
Because of the prevalence that this matter is now taking Corporate
America, many businesses and organizations are now starting to become hesitant in
using it. For example, according to the latest research report from Anaconda which
is entitled the “2021 State of Data Science Report: On The Path To Impact”:
*41% of respondents are fearful of using open-source APIs’
*23% of the respondents will not even allow its use anymore.
But let us face reality here. Getting rid of APIs as a whole is not a good
idea at all. As mentioned, your software
development teams will then have to write and compile new lines of code right from
scratch, which is a task nobody wants to do at all. So the key now is how to double check those
APIs for any holes or vulnerabilities. Here
are some possible ideas that you can make use of:
1)
Everybody should be involved:
This is why DevSecOps exists in the
first place. The goal here is to have multiple
eyes looking for areas of weakness that the other set of eyes may have
missed. One great way to get started with
this are the frameworks that are offered by both NIST and the OWASP. They have free, downloadable checklists that
you can use which are fairly comprehensive. But you also need to have something
extra in hand as well that fits the unique needs of the DevSecOps team. This is where the Software Bill of Materials (aka
“SBOM”)will come in handy. This is also
like a checklist, but instead, it lists the origins of all the source code that
has been used to create the web application.
More information about how to create one can be seen at the link below:
The SBOM serves as a starting point
from which you can access the version history of the source code as it is being
developed.
2)
Make use of automation:
I may sound like a broken record on
this one. Yes, I know AI and ML have been
one of those techno jargons that has been thrown about and beaten up extensively
now with a lot of hype into it, but I think (cannot say for sure yet) that
these days may be over. Why do I say
this? Well, it all comes down to the fact
customers want real solutions now. They are tired of fake promises and fake
results, they want something now that will truly work in their favor. With this being said, the newer AI and ML
innovations that are being carried out now do bring some solid value to the table
finally. In fact, there are solutions out there now that have been specifically
designed for the testing of APIs in particular.
Even though with DevSecOps there are more eyes available for scrutinization,
they too can get tired. But AI and ML
automation. Therefore, it is important that
you make use of both.
3)
Contribute to the overall effort of the API:
There is often a tendency to think that
by taking over an entire open-source project and bringing that in house is a
good idea. The common line of thinking
here is that you will now have control of all of the APIs, so the checking and the
repairing of them will now go quicker and smoothly, instead of having to depend
upon others in the open-source community.
But, this can actually back fire on you.
This is often referred to as “forking a project”. Remember, although open-source APIs are free
to use, it does not mean that you can scarf the whole thing up, because others
have contributed to the creation of them as well. In fact, you will probably not even get the support
and backing of the community that developed those APIs. So rather than taking this extreme approach, it
is far wiser to approach the community that developed these APIs and ask how
you can contribute to further its cause in terms of ensuring that they are safe
and updated to use. Even remember here
it, it takes team work to build a quality set of APIs that everybody can use
and deploy. More information about this can
be seen at this link:
https://dodcio.defense.gov/Portals/0/Documents/Library/SoftwareDev-OpenSource.pdf
My Thoughts On This:
If you haven’t noticed, the common theme here in this blog
is teamwork, and that is now one of the key missions for any type of DevSecOps
teams. Remember, it now “takes a village”
to combat the Cyber threat landscape, and in the future, it could very well even
take more villages. Finally, more
information about the study from Anaconda can be seen at this link:
No comments:
Post a Comment