Business Asset Analyst

Video Activity
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *

Already have an account? Sign In »

13 hours 9 minutes
Video Transcription
Hello and welcome to another penetration testing execution Standard discussion. Today we're going to be looking at business asset analysis within the threat modeling section of the Pee test standard. Now a quick disclaimer, any tools or techniques that we go over here could be used for system hacking.
And so anything that we discuss or demonstrate should be researched and understood by the user of the tool or technique.
Please ensure that you understand any applicable laws and regulations within your area regarding the use of such tools and techniques so that we don't get into any trouble with the law is we're learning and having fun.
So let's jump into our objectives for today's discussion.
So at a high level, we're going to be looking at what is business process analysis or business asset analysis. In this case, business process analysis is going to be the next discussion. We're going to discuss organizational data,
employee data, customer data and human assets. So really just examples of those information sets so that as we're looking at, what assets are foreign organization, we take those things into account. I mean, printers, chairs, anything could be considered an asset, but we're gonna focus on
particular types of information that may be of value to an attacker
or threat actor. And there may be some things that we don't cover here, but we're going to try to cover as much of those as possible.
So to get started, What is business asset analysis? Well, an asset centric view is taken on all assets within the organization, and business processes that support them that are included remember within the scope. So if it's not included within the scope, then we shouldn't be
analyzing anything within that area. By analyzing the gather documentation and interviewing relevant personnel within the organization, we can identify the assets that are most likely to be targeted by an attacker, what their value is and what impact
of their partial loss would be, or total loss in some cases.
And so again, in order for us to quantify risk. In order for us to provide a return on what the client is putting into the test, we have to be able to understand the value that these assets bring to the organization.
If we're not able to do so and we can get into a system we can attack a system we could potentially, you know, not that you would in scope, but encrypted system is a threat actor.
If the system is of no value,
then there's no reason for me to go through the effort or take the time to do so. It would be better off for me to use them is ah is, ah, stepping stone to other organizations or to use their assets or systems for resource purposes. And so,
by understanding these data sets and applying kind of what is critical in what is not to our testing efforts, we can provide real results for a client with respect to risk identification, threat identification and overall risk reduction, which is our goal as a penetration testers security tester.
Now let's step into organizational data and start looking at some examples of organizational data. So policies and procedures and plans could be important to an information to an organization because the information that they contain could be sensitive, confidential in nature. It could
bravado. This isn't an attacker with additional context
product information, so patents trade secret source code that could be very beneficial if I were to get secret sauce information and sell it Thio competing organization or, if it were to quot fingers, appear randomly at that. You know, competitors organization,
marketing information. So planned promotions launches product changes that could be beneficial to again a competitors. It can be beneficial to the attacker because they understand what new systems were launching. What software's we may be updating what things we may be doing that would allow them to get an edge
on the organization. Now, financial information is definitely top of mind bank account data, credit card information, particular investments that we've made. The 1st 2 are an easy win for an attacker you know sell well, investments and things that nature will
provide additional insider information or particularly, maybe competitive information to see what
the organization's putting its money into and words focusing its attention
to continue the discussion on organizational data. Technical information is going to be king as well. Infrastructure design information, especially when its current and up to date system configuration information, user account credentials or a major plus and then privileged user accounts information that's a plus plus.
So if we can find
plain text data if credentials are out there on the Web, if
that information is just lying around. You know, that's going to be huge. And so if we're evaluating ah, particular system and it seems rather plain in nature, but then we find it's where everybody storing their credentials sets. That system has just elevated itself with respect to its level of criticality in our analysis and in our review.
Now, employee data
is very, very, very important as far as understanding where that data lives, what the direct effect of that data would be a SW far as if it were impacted and compromised or obtained.
And so national identification numbers, p I personally identifiable information, protected health information and financial information.
If any of these given categories, at least in the U. S. Eyes compromised, I can tell you that there's typically some form of reporting practice that has to happen by law and protected health information brings into port HIPPA.
I know that, um,
overseas you've got GDP are and some other regulations that would govern the protection of personal information and reporting requirements. And so
if this information is impacted, there are definitely some reporting requirements. It would definitely be some damages, and so it's good to know where this data is stored,
especially if it's in scope, where it's stored, how its access, what systems use it. How is it protected? What's going on with it? That way we can again properly map threats to those particular data sets
now not just employees data, but customer data is also important to keep in mind as well. So for a medical practice where dental practice were surgeon, where some type of accountant tax prep person, whatever the case may be, if you
take orders and part of that is just having some P i Ay and some financial information, like a credit card on file
that could be detrimental if it were to be compromised. Because now you know, with employee data, you still have to report you can, you know, let everybody know what's going on and ensure that
everything is is addressed and taken care of, and that that information is protected with customer data. That stinks even more so because now we have to reach out to customers. Tell him that we lost stated that the data was potentially compromised. That damages reputation that damages brand. All of those things need to be taken into consideration when we're looking at threat modeling.
Um, and we're looking at how we're going to approach
our test
in customer data. Supplier data is also a big deal is well, because if your suppliers air known, if your business connections were known,
that can open them up to attack so they could be used. Potentially is a stepping stone into your network that they have vulnerable Softwares that maybe could be taken advantage of. And your systems are relatively secure
now. We also want to look at human assets within the organization. So when we identify human assets, we have to remember that the context is having such assets part of a greater effort to compromise the organization. So human assets are identified, his business assets that could be leveraged to help us divulge information.
So we want to get some information out of them. We want to manipulate,
um, to make decisions or actions that would adversely affect the organization or unable on an attacker to further compromise it. So we're talking fishing spear, phishing, social engineering, pretexting, whatever the case may be. There
executive management, executive existence or great cause. Those are the folks that have either access to executives or their information. Or they are the primary decision makers for the organization.
Middle management is good. They've got authority as well. Technical and team leads or great technicians or great. These are folks have access to systems and information.
You would hope that these folks are a little savvy er and avoiding social engineering. And, um, you know, interacting with payloads. But things happen. Sometimes people get relaxed.
Middle management. Um, you know, if you're Impersonating executive management than you could put pressure on middle management, so that could be a good thing there. And then if you have access to executive management information, then you could likely use that to manipulate executive assistance.
So you can see where human assets understanding those assets, having access to those assets information
could be used. Thio. Really. We've a good web for social engineering,
so definitely want to take those assets into account. And Human Element is definitely a component of that for threat modeling.
So let's do a quick check on learning.
True or false personnel are not considered business assets and should not be a part of any risk assessment or threat modeling effort.
Well, the cat's out of the bag on that one. We just discussed it.
That is, false. Personnel are considered business assets and should be a part of any risk assessment and any threat modeling exercise that you're doing. The human element in any note in any book
is considered the weakest element in any chain in any security practice, because we trust by nature,
we, you know, want to help. We want to do what we can do to make someone else's life easier.
We understand what it is. T need something right away or to be in trouble. So definitely the human element has to be considered in any part of a threat. Modeling, exercise, risk assessment, penetration, test, et cetera.
So we went through quite a few things today. We discussed what a business asset analysis is and what we look at. Within that, we talked about some data types, such as organizational data, you know, technical information, processes and procedures. We looked at employee and customer data such as
national identification numbers, P i E. P H. A. P. A job
in that process, and why that information is important and kind of some impact If either of those data sets were compromised, and then
we discussed the importance of
looking at our human assets and ensuring that they're taken into account when we're doing any threat modeling or risk assessment activities. So with that in mind, I want to thank you for your time today, and I look forward to seeing you again soon.
Up Next