Welcome to People, Process and Operating System Fundamentals for Cybersecurity

My name is Alex, Role Manager for the NSIEM Administrators

here in Costa Rica. My team is responsible

for monitoring cybersecurity threats

for IBM and clients, and acting upon

those threats to minimize any client's risk of

data loss or exposure. As I look to hire new cybersecurity analyst

and administrators, I look for technical skills, including operating

system knowledge, such as Linux, Mac OS, Windows, database knowledge,

cross-site scripting, malware, DDoS, and cybersecurity

knowledge in general, especially around

firewalls and antivirus. Soft skills as

effective communication. This is needed to engage

the right people. Critical thinking,

since every incident is different from day to day. Motivation, since analysts are the initiators have

to have the have the drive to pursue

the solution to problems. In this class, you will hear from several subject

matter experts from IBM globally who

will start to build your skills on important

cybersecurity processes, those resources, and

terminology. Thank you.

Overview of People, Process and Technologies

As you just learned in

Alex's welcome to this course, understanding the

fundamentals of security is essential to the cybersecurity analysts day-to-day duties. Hi. I'm Luke Fuca, a
course developer for
IBM's Data Security portfolio. I'll be with you

through course 2. To help tie together

the material, you need to master

to be successful as a junior

cybersecurity analyst. You'll be taught by IBMs cybersecurity experts who will take you through modules

on system fundamentals. We will show how

people, processes, and technology, can affect a company's overall

cybersecurity posture. You'll learn how the service

management framework impacts an enterprise's ability

to respond to a cybersecurity threat.

Are you ready?

Frameworks and their purpose

In this video, you will learn to describe the purpose

of frameworks, baselines, and best practices in an effective

cyber-security strategy. The last part of

these session is frameworks, and there's four purposes. We're going to talk

about frameworks, we're going to talk

about best practices, and here are just a

good differentiation between best practices, baseline frameworks,

normative and compliance. So in the organization, we will have a lot of things. We'll have, for example,

best practices, we will have a baseline, or we will have framework. A good example of

framework is copied, or good example of

best practices in some cases spraying worried bent up

your business is ITIL. So those are good things, good controls that will improve, enhance your IT
governance, your IT processes, your IT

policies, your IP procedures. Those frameworks, those baseline, those best practices will improve the
performance

of your servers. For example if you go and grab the best practices
for Microsoft regarding the hardening of their database server

for example, you will have a best

Microsoft SQL Server. You will have improved

Microsoft SQL Server. But that best practice, that framework is not something that you

will have to have, is nice to have. You will have a lot

of good practices, you will a lot of controls, you will have a lot

of good things. But if you don't have it, that's something that will not necessarily

harm your business. If you don't have guidelines from Microsoft to implement

the servers, if you don't have the guidelines from the Cisco to implement

the Cisco devices, if you don't have

the best practices from COBIT to improve

your IT governance your company, you will lose your business. You will be part of any problem with your
regulator or

with your government. In the other corner, we have normative and compliance. The difference here is
you

need to implement normative, you need to have compliance if your business require that. So for
example, there is

nothing called HIPAA. HIPAA is normaltive

that will be part of any healthcare company

in United States. So you could have in

your healthcare company, you could have COBIT, you can have a lot

of ITIL processes. You can have all the

best practices from your vendors implemented

in your systems. But if you don't meet, if you don't comply with HIPAA, if you missed

two processes in HIPAA, probably you won't

operate in United States. You will have penalties from the US government because you are not
complying with HIPAA. So that's the main difference between baselines framework

and best practices, and normative and compliance. So as we mentioned, we

have a lot of things. We have for example as

best practices, as frameworks, methodologies that we could implement in our business

to improve the way that our business deals

with technology and we could mention out I've actually already mentioned

a couple of those. We could mentioned COBIT, we can mention ITIL, ISOs. On cybersecurity, we

have ISO 7000 series. We have COSO. We have the PMI, the Project Management Institute with a lot of
project

management methodologies. We have the developer

recommendations, as soon as you start working

with programming languages, you will have a lot

of documentation, you will have a lot

of information regarding the best practices

that you could follow on your software in your systems to avoid any security incidence, any incidence
that will harm or will destroy your software.

Roles in security

In this video, you

will learn to describe the various roles typical to a Cybersecurity organization. Roles in information
security. Even though this is not

the complete list of roles, because each

organization may have specific roles for different

information security areas. These are very common roles that you can find in

large organizations, like the chief information

security officer, which we can say fairly new role introduced

to make sure that there's a head and someone in charge of the Information

Security Division to supervise, managed, and be the leader of the Information

Security Tower. Then we have the information

security architect, information security

consultants specialist, information security

analyst, security auditor, security software developer, the penetration tester

which is also known as member of direct team,

a vulnerability assessor. We also have the digital

forensic analyst, who is part of

the blue team for instance. We also have the SEM engineer, the person who is familiar with different
SEM technologies. So all of these roles

are very important. If you notice they already existed in

the IT realm, but however, we are now adding

the security portion to these roles to make

them more specific, and make sure that they

are security oriented. So they make sure that

they guarantee that the organization follows security best practices

and standards. To mention a few of the roles, we have the chief information

security officer. As mentioned before, this is a high level management position. This is the head of the

security department and staff. Okay. So this person

is responsible for supervising the entire

security department. It's a very important

role that in the past was not very common, but it is now very common to see this specific position or this
specific role

in organizations. Now the information

security analyst is more of a day-to-today analyst. This person is in charge

of analyzing events, alerts, alarms, and

any information that could be useful to

identify any threats. So this person should be

able to verify for instance, or analyze events that

are collected by a SEM, like I don't know, maybe [inaudible] for instance, be able to understand and
investigate alerts from

this specific SEM platforms, or any alarms related to any health check

of a specific devise, anything that could actually

lead to a potential threat. For instance, if an IPS is sending a threat alert

to the SEM, an information security analyst should be able to go to the SEM, get the alert,

investigate the events, and even go to the IPS to understand what

exactly trigger it, and be able to follow up

on that to a resolution. The information

security auditor on the other hand is in

charge of testing the effectiveness of

computer information system to make sure that they

follow best practices, they follow standards,

a specific regulations, like the ISO 27001

or 002 for instance, that they follow

at least the best practices defined in those revelations, and that organizations are

as protected as possible.

Introduction to Process

In this video, you will learn

to discuss how processes are important to our everyday

lives and for IT security, and discuss the definition of

Security Operations Center. Hi, welcome to the training on business process management

and IT security services. My name is Joe Speno, and I am a business process

analyst at IBM Corporation. Today I'd like to provide some insight and training

after we go through in a little bit of

an introduction on business process

management or BPM, IT infrastructure library,

commonly referred to as ITIL, and lastly dig in a little deeper on some of

the ITIL processes. This all relates to

IT Security Services, and let's get started. Processes are part of

our everyday lives. We are engaging in processes personally and professionally. An example might be
what

I experienced yesterday. I had to get some money

from my checking account, so I drove over to

my local bank, the ATM machine. I inserted my debit card which really kicks

off the process, and internally what I'm not seeing as the customer

on the outside. Internally within

the bank system, it's going through a series

of validation checks, looking at my card, trying to make sure

there was no fraud involved that my card

wasn't reported stolen. So it's got a validation process, these are steps it

takes eternally. Then I plug in my PIN number

and it validates that. The system retrieves

my account information, it'll go in and look

at my account balance, so I have enough money in

there to draw some out, and it completes all

of its checking. It asked me, "How much

you want to take out?". I answer the amount

in the keypad. It will ask me how I'd like

that and what type of bills. It updates my account

and dispenses the cash. Cash comes out,

my little card pops out, and the final step in the process it spits out a little receipt that

I take and drive off. So this clear process

had a start and end, and I initiated it by

putting my debit card in. Now, as IT security

professionals, processes are very

important in what we do. As you all know,

the cyber attacks and alerts are increasing. The complexity of managing this environment is increasing.
The attacks are ongoing and nonstop on our IT

resources and assets. So we as IT security professionals

are required to spend more time focus and

attention on this, namely the security analysts. So it's important to have

skills, processes, methods, and standards, because

protecting our companies from outside cyber attacks is a critical job and very

much needed today. The people, the processes,

and the tools, that we will use as IT professionals all need to work in harmony with each

other for a given process. The Security Operations Centers

and they may be called something different

in your company or in your experience, but it's basically

a pool of skills and resources that work to detect and investigate

and stop threats. With an IBM, we call them Security Operations Centers,

SOCs, for short. In the SOCs, it's imperative we have the right skills a staffing. We have the right tool

sets, for instance, automation because

if we can automate formerly manual tasks that will increase

the speed with which we can't fix

any issues that arise. So skills, tool, sets, and processes, So people, tools, and process is

the industry way to look at the threefold model. A key to success is

the implementation of standard, repeatable, and measured process.

Business Process Management Overview

In this video, you will learn to

define a process and its attributes, described standard process roles, explain

what makes a process successful and describe process performance metrics. >> I wanted to take us
through

just an overview on business process management or

commonly referred to as BPM. Now, there are varying

definitions of a process depending on the author or the source. And I should say some may call it BPM,

business process management. In your company, it might be called QPM,

quality process. There's Six Sigma, there's Agile,

ITIL, CPI, different names, but underneath, it should have the common

elements that we're striving for. So a process is basically

a set of defined repeatable steps that take inputs,

as you can see in the chart here. Add some value, there's some processing, there some knowledge
applied,

skills applied, resources within the process

that produce a required output. And an output that meets

customer requirements, whether that be internal or

external clients, customers. Attributes of a process,

every process should have inputs. That is, some information, some data or even raw materials that come
in to

the process that are used by the process, and many times are a way

to kick off the process. In my simple example, it was me putting my debit card in

the ATM machine, that was the input. Every process should have a start and

an end as well. Outputs, are what the process produces,

whether it be services, whether it be support or

an actual physical product or widget. And it has to satisfy the original

customer requirements. Each process should be bounded,

it should have a front and a back, it begins here, it starts here. We do these tasks and it ends here. They
can't just go on and for

an item, we got to have a bound. So inputs, outputs, start, stop, tasks, steps, some column, actions,
perform, it's the doing part of a process,

that will lead to an output. Another key aspects,

I don't have listed on the chart but documentation is critical in what we do. We do have to have our

process to be documented. For training purposes, just for

common understanding of how it works, for auditing purposes, for compliance. And in my experience at
IBM,

I've always liked to use kind of a three fold approach to documentation versus

a high level a one page very high level. Here's where it starts,

here's where it ends, and here's a couple of boxes that shows what

happens in the middle of the process. So just a one page, and

then I'm mid level, which is more what we call

swim lanes process flows. Left to right,

it looks like an Olympic swimming pool. Each role in the process

will have its own lane, and we list a task on the hand

off between the lanes. Let's call this swim lane. And that describes

the versus the last level I like to describe it as the how,

or the desk procedure. This is how I complete task a, b, and c. This is what I signed into and

this is how I complete this. So high level, mid level,

the what and low level, the how. Now, this is certainly very high level,

but each process unless it's fully automated. And all system generated like

my bank example most of that was system behind the scenes,

no people involved other than myself. But you could have a supplier that's

providing something to the process team. You could ever requestor, that is

requesting something of the process team that most of the time

kicks off the process. And then within the process,

you might have, and we see that a lot within IBM,

we have a team leader. Very experienced person

that oversees a group of folks that are executing the process. And is there to lend support,

to help when issues come up, that person is often in SME,

subject matter expert, it could be the same person,

team lead SME. And then you have some type

of processor or person, it's really the person executing a step or

steps in the process. And more often than not, you have

some tasks or some actions need to be approved by management or another function

before you can proceed in the process. So you need an approval and a reviewer. A reviewer might be

a quality assurance person. The one critical item to know for any role

in a process team that there should be a separation of duties such that

an approver is not the requestor. Because that would not be good

sound business practice for me to request something,

and then by the way, I approved my own request,

that would be less than desirable site. I would suggest a separation

of those duties. So what makes a process successful? And there's certainly more than six. But a charter,
it's kind of like the menu, it describes what the process

is in place to do. Why does it exist? What are the goals of the process? Who are the stakeholders in the
process? It can be from 1 page to 30 pages,

I've seen very long ones with charter. But it basically just if anyone

comes along and says, what? I don't understand what this process does,

what it's for. Here, read the charter. Process should also have very clear

objectives that when met fully, that leads to you meeting

your overall goals. Governance/ownership, I always

suggest a process owner that is not a doer in the process, rather they have accountability for

the success of the process. They are the focal point to

upper management that says, let's go talk to Joe about how

the process is performing. So they've got a name of

the accountable person, it could be a manager or non manager. But just someone that is assigned the

ownership of the success of that process. Repeatability, this so

important because that output, we want the outputs to be the same

every time, we don't want them to vary. If we're producing breaks for

a car, we want them to be the same every time they come off

the assembly line, and variation is bad. So if our steps in the process

have a little differently every time based on if person

a does it this way and person b likes to do it a little

bit different just by preference. That could lead to variation which

could affect that output, and we don't want that. Automation is important too,

because if we can reduce manual keystrokes which are prone to finger error,

it'll save time and money as well. And then lastly, but not all

inclusive is performance indicators, tangible metrics that we collect. We look at as a team monthly,

quarterly to say, how's our process doing? I want to give just a very

simplistic example of how it's important to reduce variability. If we look at just a fictitious company,
or in our manufacturing, that makes rivets that go into the assembling

of the skins on commercial jet wings. We've all seen examples of

where there has been breakage, catastrophic failure of some of the skins

because of rivets which is an awful thing. But in this example,

this fictitious example, the RR&R quality assurance team

reviews data on a defect rate, stress testing, rework, and

cost on a monthly basis. So they collect metrics,

they're interpreting, what are the metrics telling us? They're trending amount, they're looking

at comparison of two different things. For example, process costs. The cost to produce is

going down month to month. However, if they look at that solely,

that looks great, that's a good thing, class are going down. But if we take into

consideration the quality and the defect rate,

if the defect rate is going up. In other words,

if I produce a million rivets and two are defective,

that's two opportunities for failure of a skin on

a commercial jet wing. So in this industry, I would imagine

they have very strict tolerances that a widget has to be produced

within very strict guidelines because we want zero failures of a rivet

at 30,000 feet in the air. So just just a very simple example of how

important it is to reduce variability. And so

that that rivet is the same quality, high quality every time

it comes off the line. Process performance metrics,

we need to measure our process so we can understand and

improve our processes. Here, are just some common examples

I'm sure there are many more and many other types might fit

under the umbrella of these. Cycle time is basically

the timing of an event, a series of steps, or end-to-end process. My process starts here, the clock starts.
Two days later, it ends,

and I have an output. So my cycle time is 48 hours

to produce this one item. And cycle time can be many

different variations, that could be start to

finish up a process. It can be subprocess

within a bigger process, we've measured delays

before I'm in the process. I go from step a to b, and

I'm waiting to get to step c because I need information

from another role, and I had a wait on average 24 hours. So we want to measure delays,

bottlenecks and those types of things,

put the clock on it. We also want to measure quality. Input quality,

we get inputs from a source. It's good to check them. Someone provides pricing

to us to start our process. We want to make sure those

prices are right before we get too far down into our process. So it's good to measure inputs, the quality
of those the quality of our

outputs like in the Ribbit example. And in process,

just meaning within the tests that we're performing, measure the quality. A lot of companies do
sampling too,

they'll sample so many orders or processing items,

they will sample them. Costs is just as it says, what

are the costs of delays of the effects of overtime for the staff having

to work those type of things. The last category is rework,

which I just simply see a do overs. I got from step a to p and I've all

of a sudden realize something is off, I need to go all the way back

to step d and start over. So I've got all that waste of time of

my time, maybe system operation time. Maybe I need new materials and

manufacturing, I might have to scrap materials and

start over that's costly. So there's a cost to rework, and

we want to measure it then find out why. There is rework. And then go upstream and

eliminate that root cause. Continual and process improvement

refer to a lot as CPI is critical. It's just the ongoing cycle of always
reviewing your process performance matrix, what are your customers

telling you feedback wise. You can do a material assessment

which are predeveloped checklist, questions that you can self administer, that will give you a score

at the end to say, you're on a five point scale my

process is a 3.5 in maturity. Maybe I want to get to a four in

a year and here's how I get there. And then financial performance, small improvement teams

are critical too because. I always think the smaller the better if

you've got the right key individuals and SMEs, to get together from

a department with the process owner. And just review this

the stuff on a regular basis, folks that are actually

executing the process. Many times have great solutions and

ideas, and in the small group forum,

those ideas will come out.

ITIL overview

In this video, you

will learn to define the IT infrastructure library,

describe service strategy, service design and service

operations as it relates to ITIL and describe

continual service improvement. ITIL life cycle. I wanted to take you

just a very high level of ITIL and their life cycle. This is not an IBM

invention or development, this was developed outside in an industry of

industry professionals, consultants, and it's been

a number of years now, but it is a great method

and framework. ITIL defined, it's really

a best practice, like I said, framework and I've seen it used across many different

types of companies, public-private sector, IBM we use it in many of

our inner organizations. I think it has been very helpful. It is a framework

provided to companies, not that it needs to be

implemented exactly as the developer's outlined

it, it's a guideline. It describes, really, how we as an IT organization need to better organize and provide

business value with all the IT processes

that we implement. The developers of ITIL came

up with life cycle phases, which I thought was really great. It's a very logical

flow: strategy, design, transition,

operations, and improvement. So it's a very logical

progression, if you will. For instance, service strategy. I'm in the IT organization

of my company. I want to have

a strategy that says, here's how I'm going to

support my customers, which are a lot of the

business units in my company. The finance group,

the marketing group, advertising, the sales team. How am I as an IT group

going to support them, and what am I going to provide? It's really taking,

understanding my offerings, my capabilities, and what I can provide to

them as my customer. Within service strategy, ITIL has developed a number of subprocesses like

the ones listed here. There are actually

more than I've listed, but this will give you a flavor of what they are suggesting. Service portfolio
management is, really, how are we going to manage the service portfolio,

what we provide. An example might be, we provide HPDA support for

our internal organization. Was that 24 by seven, there are other

certain parameters, but that is the type

of thing we'll throw into our service portfolio. Financial management is, really, how we're going to
budget, do our accounting etc to reach our strategy goals as an IT group, security group. Demand
Management is

really understanding anticipating

requirements that might come to us by our customers, whether they're

external customers, or our internal business units. Then business relationship

management is, how are we going to maintain a positive relationship with our internal customers

or external customers? What is the process

that we'll use to ensure that we hear them that we're taking

action on what they say? So that was service strategy. That was the very first. Many of our

organizations, as yours, we probably have IT processes in place and we're not necessarily developing

new strategies, but this is one way you can

take a look at ITIL against your strategy and there

might be ways you can improve and refine your strategy. The next phase or cycle

is, service design. This has to do with

designing new services, IT security services

that you might provide, as well as changes

to existing ones. Some of the subprocesses includes; service

catalog management, ensuring there is a catalog

is produced and maintained containing accurate

information of all the services that we provide. The help desk, for example, might be in that service
catalog. Service level management. Sometimes you might

hear of this as SLA management,

Service Level Agreement. It's basically those written or understood terms

between you and your customers on the levels of performance, setting targets. We're going to complete

a help desk ticket within x hours, that type of thing,

then measuring performance against

that objective. Information security management. This is, just really, ensuring the

confidentiality, integrity, and availability of

the organization's information. It's the data in the IT services. Supplier management. This is ensuring
that we have contracts with

those suppliers that we need to provide what we need as an IT security group

to do our jobs. So that was design, strategy design, and then

we go to transition. The objective of

service transition is to build and

deploy IT services, existing, changing

existing, or new. We're transitioning them from current state to a steady-state. So things like change
management, which we're all familiar with, the control of life-cycle
of all changes. That is under service transition. It's a process for ensuring we do changes with a quality
aspect. It's project management, projects that coordinate

the resources deploying, for example, like a release

within your environment. Release and deployment.

Planning, scheduling, controlling the movement of releases to test in

live environments. Within all of these,

communication is so important because this is not

an area we want surprises. Where all of a sudden there

are outages because we put a change in and no one in the business units

knew about it. So communication cuts

through all of these. Service validation and testing by ensuring that

deployed releases and the resulting services that they all meet customer expectations, whether internal
or external. The last one I have listed, and there are other subprocesses

under transition. But knowledge management

is important. This is where we seek together, analyze and store knowledge learned and information that
can be shared across

our organization, whether it's just an IT security

in your company, or across the corporate wide. So then we move into

the next phase, which is service ops,

service operations. I call this one steady-state, because we've gone from

transition, we are executing, we're in steady-state,

we're monitoring, we're executing

those type of things. Just a couple of the processes under service ops that

I've listed here. Event management is a key, that's making sure that

configuration items and services are

constantly monitored, its categorizing advance and then taking appropriate actions. Incident
management, this is managing the life cycle

of all incidents. We'll go into that a little

deeper in a little bit. Problem management,

likewise to managing the life cycle of all problems. Really, the goal of service ops
is to make sure that our IT services that

we are providing to the business units

or external clients, that they're delivered

effectively and efficiently, and that's where that whole

process discussion comes in, where reduce of variation by having standardized repeatable

IT security processes. The last the life

cycle phases of ITIL, which is one of my favorites

because this is what I've been involved in with

IBM for many years, is continual service improvement. Where it's just as it says, it's like we discussed
before. We're continually

reviewing metrics, we're identifying gaps in

current service processes, we're looking for how

we think it should be, we're trying to reduce the gaps, we're testing and prioritizing, we select what we
think is the best opportunity to

improve, and then we implement. So it's a continuous wheel. It's always trying to

improve your process.

Key ITIL Processes

In this video, you will learn to describe key ITIL

processes including; Problem, Change, Incident, Event, Service Level, and

Information Security Management. The last section I wanted to just drill down a little bit more into some
of the processes that I talked about

at a high level. There are so many

resources available, you can Google and find wikis that really go into a deep depth on all the

ITIL processes. There's a lot of organizations

that do consulting on it. But really, there's a lot

at your fingertips just by going in and Google

searching on ITIL. So this is not by

any means exhaustive. What I'm conveying here this

is just a high overview. So problem management. Responsible for managing

the lifecycle of all problems. That's how ITIL

defines a problem, an unknown cause of

one or more incidents. Problem management really aims to resolve not just the one

problem that came up, but what what's

the root cause of incidence, so we can minimize this happening again or the impact of

a further incidents. So it's really

seeking to find and resolve the root cause

of the problem. Whereas incident management

is getting things back to a returned state of the

service to normal levels. Change management is

just as it sounds, it's changes to

baseline service assets or our processes really, and configuration items

across the ITIL lifecycle. Those five phases. It's aiming to ensure that standardized methods

and procedures are used for effectively making changes. It could be changes to

configuration items, process steps tasks, systems, communication, again

is critical to reduce disruption of service

and back out activities. Some of the phases within ITIL

change management include; identification of the change, planning the change, assessing

the impact of the change, and then getting approvals or scheduling those type of things

and then implementing it. Post implementation will

do a change review. What went wrong, what

could have gone better, could we have done

something differently, those type of things. Then a closure. Again, this is all documented in much more
detail by ITIL

that you can find on online. Incident management, we talked about this briefly earlier, but this is aimed
at restoring normal service apps as quickly as possible and minimizing adverse effect on

business s. This directly correlates to service level agreements

we have in place. So an accident is

an unplanned interruption to an IT service or reduction degradation of

quality of an IT service. Some common phases it talks about in ITIL in

incident management lifecycle, would be to log it, assign it to someone that is going

to resolve, track it, categorize it, there are different ways

different organizations as to how they

categorize an incident. ITIL has its perspective. Prioritize resolve and then

close. Event management. An event may indicate that something is not

functioning correctly. The vance are any detectable or discernable occurrence that has significance for

the management of an IT Infrastructure or

the delivery of an IT service. Within an event management, we create and detect

notifications. Monitoring, the

monitoring function is key as well for checking. Service level management. This involves planning,

coordinating, drafting, monitoring, and

reporting on SLAs. We talked about that

earlier how we will have, we should have SLAs with our internal customers

or external, and have an objective

set a bar that says, Here's how we're

going to perform, and as we measure if we're

not performing to that level, we know we need to

make some adjustments. The last one that

I wanted to just outline is information

security management. This describes structured fitting of information security and

the management organization. So this is really

the crux of what we as IT security professionals

are involved with. The tabbing and

maintaining ISPs and specific policies that address each aspect of strategy,

objectives, and regulations. Some of the goals of IT security management

are authenticity, accountability, non-repudiation,

and robot reliability. I would urge you to

look more into ITIL, and business process management because it's a great framework for our IT security
organization.