to part three off enterprise security areas off cybersecurity, architectural fundamentals.
I would cover vulnerability and Pech management availability management
and a bit off supply chain security.
All of these are pretty big. Top it by himself, but I'll just cover the basics of each area.
Let's begin with vulnerability and patch management.
So what's the difference? Well,
It's the psych lickle practice off identifying, classifying, re mediating and mitigating vulnerabilities.
This includes V A testing, and it also covers zero days off vulnerabilities found in the wall.
While Pech management covers the life cycle off reviewing and applying patches to system.
This is needed to cover assessment,
testing, deployment and, in case of any failures, the rollback process.
As you can imagine, patches are usually issue to fix vulnerabilities found in products. Hence, there is usually a very close association off these two practices.
Now I will not go through all the different vulnerabilities there are that you know the track could be introducing. But today I'll focus on the threat itself on vulnerability management.
Today, people either by Intel feet or subscribe to various vulnerability assessment systems like tenable or RePet seven.
Although these service's gets you the vulnerabilities very fast,
there are still the chance off zero day vulnerabilities found.
The other tread would be people walking around certain fixes, thus negating the control measures you have in place to counter the vulnerabilities. Now, in terms of Pech management,
the biggest threat is usually insufficient. Testing. Off patches have been many cases off pech, causing other failures in the system.
And in some cases it is the urgency off the fixes that reduce the testing cycle in order to push the patch out as quickly as possible.
This can lead to patch failure, which could affect the system or introduce other new vulnerabilities that were not there in the first place.
Another big problem with patch failure
is when you try to roll back to a previous state and fails, you'll get into an unusable condition.
Therefore, pech management is justice important as vulnerability management
to have a good vulnerability management. You should subscribe to Intel feeds that help you prioritize some off these vulnerabilities,
and it pays to have environment to validate some of these vulnerabilities because it's always present in every system that it's reported. It
especially if the vulnerability is because off certain configurations that might not be used in your organization.
And you should always have a good communication plan around the systems to inform all the stakeholders. If something is found
in terms of patch management, that paste of multiple environments to really thoroughly test all the patches that you're going to apply to the systems and for the testing,
it's a good practice to have realistic test data
to ensure that the tests ISS as close to production as possible.
You also spent a good amount of time to prepare your rollback procedures and to test the robot procedures in case of patch failures.
The use of virtual technology has made this much easier with snap shotting off image and roll back to certain point in time.
Another very good technique to employ is the use of virtual patching
virtual patching. It's a technique that blocks the exploit from its signature at the network level. All the holes I PS level.
This is very useful for O T systems, where it's not so easy to schedule our downtime toe, apply a patch. The use of virtual patching is highly encourage
in environments where scheduling of patching is very difficult.
This will at least help ensure that run abilities are blocked, even if your system is not actually patched.
Now, remember, cybersecurity is C i N A. So availability is part off cyber security management
and availability. Management usually refers to two areas. High availability and disaster recovery.
High availability is concerned with up time,
and this is usually managed within the same environment as your primary system,
and this has a direct impact on your patch management strategy.
This is because many systems need a reboot after a Petch,
although not all systems do.
While disaster recovery, it's about business continuity, and it's is usually in a secondary site.
Disaster recovery affects a design based on the R. T 00 and O P O.
which is the restore time objective. Time taken to get back and running
and the wrist are point objective, which is at what stage the data restored to
the smaller the numbers of thes, the higher the costs off the solution.
And in many cases, since your recovery site it's a remote location.
This has great dependencies on your network, Ben, with that directly effects your costs.
And since it's about business continuity,
these numbers are usually dictated by the business. Check with the business owners of their systems on their recovery objective and right size. Your solution to meet the business objectives.
Now the treads to high availability could be an unstable application
a lot beyond the capacity plan.
Miss Configuration All simple equipment failure
for D Our. It's usually when a sightless destroyed a very large scale and prolonged power outage. All natural disasters such as earthquakes,
environmental trip modeling thus play a part in a lot. Off the out scenarios
knots some off the control measures you can have to achieve. Hit J
could be the use of a good look. Balancer
employer. Stateless design for the applications.
Make use of reliable messaging
that can guarantee delivery
and redundancy for everything
to counter equipment failure.
Obviously, this comes at a cost.
Some techniques to help with the old design could be taking regular snapshots.
Half transaction locks that can be replayed
or even old fashioned to face commits to remote database so that we can guarantee that the remote database would be the same as your primary production database.
Okay, moving on to supply chain security.
This covers the upstream and downstream effects of components in the system.
This is extremely difficult to manage and current I t landscape as nobody builds everything from scratch, and in many cases, vulnerabilities are introduced. True vulnerabilities in your sub components.
Some off the more common supply chain security treads of the use of open source libraries.
A scene in the open SSL case a few years ago.
Hardware supplier. For example. Intel's meltdown. When spectral vulnerabilities,
the use of shed libraries can cause vulnerabilities to cross over system.
Same for common tools and even the Kampala use as you can read the details from the link supplied.
What can we do about this? Well, always planned for alternative sauce in case vulnerabilities are found,
make sure you have update plans from your component supplier
and always plan for the worst case. Not if it happens, but when it happens
and do pay attention to Intel. Feats on exploits in Southern libraries that you might be using
for open source libraries do employ technologies like sauce composition analysis to make sure that the libraries are clean before you put them into your applications.
in this session recovered the basics of vulnerability and patch management
talked about high availability and disaster recovery for availability management and some of the areas to pay attention to in supply chain security.
This is a very good source of information regarding this. I have shut to Ling's for further reading, one on configuration inventively T management and the other in the best practice in the cyber supply chain risk management area.
Do take the time to read these documents.
Well, this concludes the basic enterprise security areas
in the next session, I would cover on a very important topic
which is cool out security. If we have the time, please join me. Thank you.