2 hours 41 minutes
Hi and welcome back to cybersecurity Architecture Fundamentals
Episode 11 Cybersecurity process is Part one
in this session will cover the type of processes in cyber security,
and I'll go over the 1st 2 which is the incident response process and the audit and reporting process. These two are extremely important. Operational aspect off cyber security
one off. The biggest mistake I've seen in people starting out in security architecture
is that the solution was done without taking into consideration
the process. Or the operation expects off a system
to have a good sustainable system. You must be consciously aware off the various processes required to keep it running.
In this cost, I will cover three of thes main processes
the incident response process, which is important because incidents do happen
and they have to be managed,
audit and reporting. It's also an extremely important part for the stakeholders
and off course risk management. Many people see cyber security. It's just in a speck off a larger risk management program.
Let's begin by talking about incident response.
As you can see from the slide.
There are many incident response frameworks out there from this to us certain I Sokka and even I s O
there is no right and wrong way to handle an incident.
It all depends on the maturity of the organization
and the scope off incident response. For example,
in a lot of commercial enterprises, the incident just needs to be closed and move on.
But in many public sector organization, it needs to follow true Tuatara investigation forensics refers engineering attribution and so on.
The key is to pick one that sits the organizational objective and the skills off the people in the organization.
The amount of incident response out sauce to an external vendor also plays a part in deciding which off the frameworks to adopt.
If you're working in an established company, I'm sure that's a process out there. And the key is to go find the right person to understand what is the process to follow.
I talked to a security operations folks to get a better picture.
If you are toss to develop and new framework,
it doesn't pay to reinvent the wheel in this case, pick one off the established frameworks and adopted to the best of your ability.
You might ask why it met us. Well, incidents do happen
and it needs to be managed. So that's the security architect off a system. The system must be designed to support the organization's ability to respond to security incidents
some off. These include the ability to get the locks they need to the investigation to get an image or memory dump, or even access to the system physically, if they need to retrieve an image off the DIS.
As the security architect, do not forget to get the requirements not only from the functional team but also from the security operational team.
Some off the questions to ask yourself when architect ing a security solution
Can incident responder, rebuild the steps up to the incident.
Are there sufficient lots for him to understand the lead up to the incident?
Two. Are you able to provide all the necessary evidence for investigation?
These includes this image is memory snapshots, locks off all the connected device
and maybe even the endpoint locks off the user Render breach occurred.
Thirdly, please consider how, with the forensics image be taken,
would it be a disc copy with a right blocker?
Would it be a snapshot from a V. M? This is not a straight for it as it seems. Asked the wall move towards things like Serverless technology and Serverless architecture.
It's gonna be a little bit more complicated as we move towards more civilised systems.
even if the locks are collected,
is it easily passed?
Are the locks generated and stand at six locks? What are the passing technologies use to put them into a sim for your operation? Folks
do keep all this in mind when designing a system for incident response capability
from a technology angle. There are some decisions to be made,
for example, in the virtualized technology to use V M a image if he used the clout to use AWS native image and so on.
How does your incident response team get these images?
Two. Where are the locks? Start in a central cysts lock depository. Our local locked directory. Please do take note with security off the lot location and who can access or temper with the locks.
Decisions on lot retention is also an important one, as this equates to costs. How long that's the incident Response team need to go back in time to build the case.
Are your system time synchronize without proper times organizations, lock or relation could be an issue.
Do all the systems you design used the same time server, for example? These are important considerations.
And where are the encryption and decryption points in your system? If the traffic is enter, when encrypted,
is their ability to do any forensics or reverse engineering, or even if this copy off the image would be useful to the forensics team?
These are all things you need to think about
auditing and reporting.
Every company has some audit and compliance team.
Make sure their input is also there. When you are protecting a solution, they play an important part
for the stakeholders.
If you're in a highly regulated industry like banking or pharmaceutical, what other regulatory requirements for your system to supply reports?
Are there any other internal audit requirements to support your internal audit? Our compliance team?
And is it easy for the system to pull at heart reports for security events? Or do you have to do in a bench? Mort,
these are things to consider
S With incident responds,
you have to consider the lock retention period for audit or even regular tree requirements. Some financial sectors require a seven year retention off logs, for example,
and some companies require a year retention of our events. Do make sure it complies to the organization. Needs
ability to pipe to a dashboard
would dictate the protocol All the AP eyes you need to open
incident reporting. Is it true a system to have a centralized sock?
Please take note off all these when designing system reporting
Key in this session recovered types of security processes,
namely covering incident response
and audit requirements. These are two very important operational process that you need to keep in mind when designing any system.
I would encourage you to talk to your internal teams in your organization to find out more about the requirements and how you can support them.
Here are two good resource is to learn more.
Firstly, there is the nous computer security incident handling guy,
although it's a bit dated from 2012
all the things inside us, the relevant today.
The 2nd 1 is an audit in psych paper by a few auditors from various companies coming together to talk about how which you audit cybersecurity today. It's a good read to find out more about the space.
That's it for this session.
In the next session, I'll go into the next area, which is risk management, another very important topic for a cyber security architect
Looking forward to seeing you in the next lecture. Thank you.
Fundamentals of Cybersecurity Architecture
This cyber security architecture class aims to give an appreciation of the various aspects of consideration that goes into a proper security architecture.