5.1 Cybersecurity Processes Part 1
Video Activity
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *
or
Already have an account? Sign In »
Video Transcription
00:00
>> Hi and welcome back to
00:00
Cybersecurity Architecture Fundamentals Episode 11,
00:00
Cybersecurity Processes Part 1.
00:00
In this session, we will cover the type of processes in
00:00
cybersecurity and I'll go over the first two which is
00:00
the incident response process
00:00
and the audit and reporting process.
00:00
These two are
00:00
extremely important operational
00:00
>> aspects of cybersecurity.
00:00
>> One of the biggest mistake I've
00:00
seen in people starting out in security architecture
00:00
is that the solution was done without taking into
00:00
consideration the process or
00:00
the operational aspects of a system.
00:00
To have a good sustainable system,
00:00
you must be consciously aware of
00:00
the various processes required to keep it running.
00:00
In this course,
00:00
I'll cover three of these main processes,
00:00
the incident response process which is important because
00:00
incidents do happen and they have to be managed,
00:00
audit and reporting it's also
00:00
an extremely important part for the stakeholders,
00:00
and of course risk management.
00:00
Many people see cybersecurity as
00:00
just an aspect of a larger risk management program.
00:00
Let's begin by talking about incident response.
00:00
As you can see from this slide,
00:00
there are many incident response frameworks out there.
00:00
From NIST to US CERT,
00:00
ISACA, and even ISO.
00:00
There is no right and wrong way to handle an incident.
00:00
It all depends on the maturity of
00:00
the organization and the scope of incident response.
00:00
For example, in a lot of commercial enterprises,
00:00
the incident just needs to be closed and move on.
00:00
But in many public sector organization,
00:00
it needs to follow through to a thorough investigation,
00:00
forensics, refers,
00:00
engineering, attribution and so on.
00:00
The key is to pick one that suits
00:00
the organizational objective and
00:00
the skills of the people in the organization.
00:00
The amount of incident response
00:00
outsource to external vendor
00:00
also plays a part in
00:00
deciding which of the frameworks to adopt.
00:00
If you are working in an established company,
00:00
I'm sure there's a process out there and the key is to go
00:00
find the right person to understand
00:00
what is the process to follow.
00:00
Talk to your security operations
00:00
folks to get a better picture.
00:00
If you are tasked to develop a new framework,
00:00
it doesn't pay to reinvent the wheel in this case,
00:00
pick one of the established frameworks
00:00
and adopted to the best of your ability.
00:00
You might ask why it matters.
00:00
Well, incidents do happen and it needs to be managed,
00:00
so as the security architect of a system,
00:00
the system must be designed to support
00:00
the organization's ability to
00:00
respond to security incidents.
00:00
Some of these include
00:00
the ability to get the logs
00:00
they need to do an investigation,
00:00
to get an image or memory dump,
00:00
or even access to the system
00:00
physically if they need to retrieve an image after this.
00:00
As a security architect,
00:00
do not forget to get the requirements not only from
00:00
the functional team but
00:00
also from the security operational team.
00:00
Some of the questions to ask yourself
00:00
when architecting a security solution.
00:00
First off, can the incident
00:00
responder rebuilt the steps up to the incident?
00:00
Are there sufficient logs for him to
00:00
understand that lead up to the incident?
00:00
Two, are you able to provide
00:00
all the necessary evidence for investigation?
00:00
These includes this images, memories, snapshots,
00:00
logs of all the connected device,
00:00
and maybe even the endpoint logs
00:00
of the user when the breach occurred.
00:00
Thirdly, please consider how
00:00
would the forensics image be taken?
00:00
Would it be a disk copy with a write blocker,
00:00
would it be a snapshot from a VM?
00:00
This is not as straightforward as it seems.
00:00
As the wall move towards things like
00:00
serverless technology and serverless architecture,
00:00
it's going to be a little bit more complicated as
00:00
we move towards more serverless systems.
00:00
Fourthly, even if the logs are collected,
00:00
is it easily passed,
00:00
are the logs generated and standard syslogs?
00:00
What are the parsing technologies used to put
00:00
them into a sim for your operation folks?
00:00
Do keep all this in mind when designing
00:00
a system for incident response capability.
00:00
From a technology angle,
00:00
there are some decisions to be made.
00:00
For example, in a virtualized technology,
00:00
do you use VMA image if we use the cloud
00:00
to use AWS native image and so on.
00:00
How does your incident response team get these images.
00:00
Two, where are the log stored in
00:00
a central syslog repository or local log directory.
00:00
Please do take note of the security of
00:00
the log location and who can
00:00
access or tamper with the logs.
00:00
Decisions on log retention is also
00:00
an important one as this equates to cause.
00:00
How long does the incident response team need
00:00
to go back in time to build the case?
00:00
Are your system time synchronized?
00:00
Without proper time synchronizations,
00:00
log correlation could be an issue.
00:00
Do all the systems you
00:00
design use the same time server, for example.
00:00
These are important considerations.
00:00
Where are the encryption and
00:00
decryption points in your system?
00:00
If the traffic is end-to-end encrypted,
00:00
is their ability to do
00:00
any forensics or reverse engineering.
00:00
Or even if a disk copy of
00:00
the image will be useful to the forensics team.
00:00
These are all things you need to think about.
00:00
Moving on, auditing and reporting.
00:00
Every company has some audit and compliance team.
00:00
Make sure your input is also
00:00
there when you are architecting a solution,
00:00
they play an important part for the stakeholders.
00:00
If you are in a highly regulated industry
00:00
like banking or pharmaceutical,
00:00
what are the regulatory requirements for
00:00
your system to supply reports?
00:00
Are there any other internal audit requirements
00:00
to support your internal audit or compliance team?
00:00
Is it easy for the system to pull ad-hoc reports
00:00
for security events or do you have to do in a batch mode?
00:00
These are things to consider.
00:00
As with incident response,
00:00
you have to consider the log retention period for
00:00
audit or even regulatory requirements.
00:00
Some financial sectors require
00:00
a seven-year retention of logs,
00:00
for example, and some companies
00:00
require a year retention of all events.
00:00
Do make sure it complies to the organization needs.
00:00
Ability to pipe to a dashboard will
00:00
dictate the protocol or the APIs you need to open.
00:00
Incident reporting.
00:00
Is it through a system,
00:00
do you have a centralized SOC?
00:00
Please take note of all these
00:00
when designing system reporting.
00:00
In this session, we covered types of security processes,
00:00
namely covering incident response and audit requirements.
00:00
These are two very important operational process that
00:00
you need to keep in mind when designing any system.
00:00
I would encourage you to talk to
00:00
your internal teams in your organization to
00:00
find out more about
00:00
the requirements and how you can support them.
00:00
Here are two good resources to learn more.
00:00
Firstly, there is
00:00
the NIST computer security incident handling guide.
00:00
Although it's a bit dated from 2012,
00:00
all the things inside are still relevant today.
00:00
The second one is
00:00
an audit insight paper by a few auditor's from
00:00
various companies coming together to talk
00:00
about how would you audit cybersecurity today.
00:00
It's a good read to find out more about this space.
00:00
That's it for this session.
00:00
In the next session,
00:00
I'll go into the next area which is risk management.
00:00
Another very important topic for
00:00
our cybersecurity architect to know.
00:00
Looking forward to seeing you in
00:00
the next lecture. Thank you.
Up Next
Similar Content
