Business Process Analysis
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *
Already have an account? Sign In »
Hello and welcome to another penetration. Testing, execution Standard discussion. Today we're looking at the other side of the coin business process analysis. We just recently looked at business asset analysis,
and so we're going to jump into looking at business assets and time in the particular process pieces to give us an overall picture
of how the organization works and critical processes within that, so is a quick disclaimer. Pee Test videos do cover tools and techniques that could be used for system hacking. Any tools discussed or used during our demonstrations should be researched and understood by the user.
Please research your laws and regulations within your given area to ensure that the use of these tools or techniques
it does not land you in any trouble with the law. So let's go ahead and look at our objectives for today's particular discussion.
So we're going to look at what is business process analysis defining that and discussing it. We're going to look at and discuss technical infrastructure, supporting processes, information, asset supporting processes, human assets, supporting processes and third party integration and or usage of by process. So,
essentially, how does 1/3 party plug into our overall business and the
core processes that we need to function and operate.
So let's jump to our first slide on business process analysis and what that is. So in the business process analysis, we differentiate between critical business processes and non critical process is so for each category, the analysis is the same and consider the same elements. The main difference in is, as in waiting
from a critical business process or against a critical business process that is a sign with, as
opposed to a non critical one. So in this case, critical processes could be considered paywall processes shipping process sauce making process if you've got a secret sauce that you're making invoicing process, and the reason for that is
is if we can't invoice, we can't,
you know, get paid. If we can't get paid,
we can't do payroll. If payroll doesn't function, we can't pay people. We can't pay people. We can't make sauce if we can't make sauce, we can't do invoicing and do payroll. And if we can't make you know if we can't ship, we can't ship the sauce. We can't do the invoice and you can see where that would get convoluted and complicated.
And so one of my recommendations
as you look at the system
are you identifying asset? Let's just say it's asset A
and you're working on these different areas and identifying how they connect to system a map out. You know, there's payroll and invoicing tied to system A. And as you continue to look at these different areas within business process analysis, technical infrastructure, et cetera,
build you kind of a Web, or if you've got a tool that you use multi go.
You could just use that to kind of lay everything out our physio or there's open source components to that as well.
However, you want to map things out and lay things out for easy reference, I would definitely do so. Don't try to memorize everything and keep everything in your mind
now. Technical infrastructure supporting process. So when we're looking at that,
they're supported by infrastructure. Usually, business processes are and so this is things like computers, networks, processing, power PCs. Whatever the case may be, there's something that's tied into a critical business process. Somewhere. All of those elements have to be identified and map,
and that mapping should be clear
to be used later in the process when translating the threat model to the vulnerability, mapping and exploitation etcetera. So
when we're looking at per se payroll processing, we say that Workstation A, B and C provide payroll processing and server X Y Z is the primary payroll server.
So when we start to look a vulnerability analysis and exploitation routes and we're doing our overall threat modeling and we're scoring this particular system
or these systems, their level of criticality is elevated because they're tied to a particular process. That is, is that you know, if it were impacted or not available, it could impact the organization in a huge manner. And so we take all those things into account when we look at technical
now, information assets, unlike technical infrastructure information assets, are existing knowledge bases in the organization that are used to either reference or support critical business processes. And so such assets are usually identified in the business process already
and should be mapped alongside technical infrastructure
within your threat modeling exercise.
Now, human assets are essentially the people that make up the critical business processes, and so
when we're looking at any individuals within the organization kind of sticking with the payroll process. We need the payroll specialist
to make sure that the payroll process works
Okay, so if we don't have another resource trained
in the organization, cross trained or whatever the case may be to process payroll once a week once every other week, once a month. Whatever the case may be,
then that human element is critical
to the payroll process. And if that human element were impacted in some manner, then it could adversely affect the payroll process. So we have to note that
third party integrations or tools like human assets supporting the process there could be third party involvement with the business process as well. And so it could be tricky to map out. But we should have both the human element, the technical element, the knowledge element
and then the cloud element, essentially, in this case
for this. So let's say that the system the work station we identified A is critical.
knowledge, information or documentation that's critical.
We've got the human element
that's critical, and then all of this information in the business
ties up to
a cloud based system or sad solution
that then allows payroll, toe happen and process.
So all of that is taken into consideration when we do our threat modeling, and we're mapping out risks to the organization and looking for potential attack vectors for things that are in scope with respect to critical systems.
So let's do a quick check on Lori.
Which of the following
is technical infrastructure
With respect to our, you know, when we're mapping out a process or something of that nature? Which of the following is considered technical infrastructure?
All right, well, if you need more time, please pause the video and take a moment to look. So the payroll specialist is a human asset and is not considered technical infrastructure. The says provider is considered third party,
so a workstation used for payroll could be considered technical infrastructure in an over all process or when we're evaluating technical infrastructure. That work station is considered a part of that. Members could be network
components. It could be the network itself. It could be processing power. It could be a state of workstation and server
that all falls into technical infrastructure. Within this business process. Analysis
now in summary, we discussed what business process analysis is. We look at some different areas such as technical infrastructure, information assets, human assets and third party integration or tools all coming together to support
business processes. And so each of these areas has to be considered when we're mapping out business processes. And when we're putting those processes against business assets
to build our overall threat model threat map or do a risk assessment, whatever the case may be there.
These are some core areas that you would want to look at and review within that business process analysis. So with that in mind, I want to thank you for your time today, and I look forward to seeing you again soon.
Threat Agent/Community Analysis
Threat Capability Analysis
Finding Relevant News
Module 3 Summary