All right, what's a security policy?
Security policy is a brief high level overview document that describes specifics
of the organization related to various areas of concern.
We're going to see several examples of that.
We actually have numerous slides with different types of policies.
I'm not going to give you a bunch of examples right now because we're going to
have plenty coming up here shortly, believe me.
The security policy is a well documented
set of plans, processes, procedures, standards, and guidelines.
We've seen these terms before.
Require to establish an ideal information security status of an organization.
They're used to inform people on how to work in a safe and secure manner.
They define and guide employee actions on
how to deal with organization sensitive operation data resources.
The policy is an integral part of an
information security management program for any organization.
Policy is written, it's followed by humans.
We lay out the high level overview and then the specifics of how to implement.
The policy itself should be a brief high level overview document.
For example, all systems in X, Y, Z
Corporation should have a managed antivirus.
Okay, we all need AV.
Well, which AV?
How often does it update?
Where are the definitions files coming from?
How often do I scan? Do I do real time checking?
Am I blushing the malicious scripts?
Those are all details that need to be worked out.
That stuff would be detailed in a procedural document.
Guidelines or again, rules of thumb, generally for absence of a standard.
They all work together to provide a policy.
But that whole statement,
all systems should have a managed antivirus, continuous real time
protection, that's probably not likely to change in five or 10 years or even longer.
That statement is still going to hold true.
But the procedural document is more likely to change because you'll use new
antivirus, use new definitions files, whatever.
The procedure is more likely to be updated.
Need for security policy gives us consistency, period.
Everybody's on the same page.
You write a policy, everybody's read it, everybody understands it.
You follow the policy, problem solved, right?
Everybody's following policy.
Yeah, but it's again, the human following it.
And again, short cuts can be made.
People can fail to perform specific activities.
And again, that human is
hate to keep saying it, but that's the area that's most likely to break down.
Ensure information security standards
compliance, limit the organization's exposure, outline senior management's
commitment in maintaining a secure environment,
provide legal protection, quickly respond to security incidents,
reduce the impact of a security incident, minimize the risk of data breach.
Again, all reasons or needs for security policy.
The key elements of a security policy.
It provides clear communication, brief and clear information, easily understood,
defined scope and applicability, enforceable by law, legally compliant,
recognizes area's responsibility, and gives us sufficient guidance.
The contents. High level security requirements.
I actually just went through this when I
said, Hey, X, Y, Z company, all systems manage antivirus.
A very brief high level statement, not likely to change.
A policy description based on the
requirement, which gives you the security disciplines, the safeguards, procedures,
continuity of operations, and documentation.
The concept of operation, roles, responsibilities, and functions.
Then the allocation of security enforcement to the architecture elements,
provides a computer system architecture allocation to each system in the program.
All right, types of policies.
11 trim, boiled trim, trimp, cocktail.
Lots of different types of policies.
I'm going to give you again a couple of keywords or highlights for each one.
Enterprise information security policy
drives an organization's scope, provides direction to their security policies.
So this is something that actually is applied enterprise wide.
You're going to have application, network
and device, backup and restore, system security policies.
An issues specific security policy,
directs the audience on the usage of technology based systems with the help of
guidelines, things like remote access and wireless, incident response,
password policies, and policies for personal devices.
System specific policies direct the users while configuring or maintaining a system.
Examples would be a DMZ,
encryption, intrusion, detection and prevention, and access control policies.
Again, we're going to be talking about a
lot of these topics more in later chapters.
For now, you're just getting a rough idea.
Are these exhaustive lists of every
possible example of an enterprise information security policy?
No, it's just a brief thought jogger list just to give you some examples.
Security policies.
Examples of.
Internet access policies.
A promiscuous policy means no restrictions on anything.
That is not the most secure way to go about doing anything.
Let's just leave it wide open and just
lock things down as we discover dangerous activities or whatever.
In internet access, no restrictions on internet, nothing's blocked.
That is going to get you killed quickly.
No gatekeeper in the front door.
A permissive policy starts with no restrictions, which means
starts promiscuous, but then known or dangerous services or attacks are blocked.
You start blacklisting things one at a time.
Known holes are plugged, known dangers stop.
But what happens in the meantime?
Unknowns, zero days, things like that are still left unaddressed.
We know about certain dangers and we also
don't know about a lot of dangers that haven't been discovered yet.
So probably not the greatest way to go about it.
In a prudent policy, this is probably our best option.
Provides maximum security, allowing known but necessary dangers.
All services are blocked, safer necessary services are enabled individually.
Everything is locked down.
Only what could be made safe is allowed. There you go.
No laps in security, at least that's the idea.
In a paranoid policy, everything is forbidden.
No internet connection or severely limited
internet usage, and users find ways around overly severe restrictions.
If you make something too prohibitive, people find ways around it, guaranteed.
Probably the best example of that, which
we don't really have modems anymore, was not having remote access at work and
people installing modems at their desk with their desk extension and dialing into
their corporate PCs and not applying security.
Thankfully, modems are not a huge issue anymore.
They're still out there.
But boy, that's what got me sucked into this whole thing.
I was mesmerized watching the movie War Games and that war d atling thing.
I'm like, Oh, that is too cool.
I've got to try that out.
Our acceptable use policy.
Everybody that gets hired by an
organization will sign an acceptable use policy.
It
defines the proper use of an organization's information, electronic
computing devices, system accounts, user accounts, network resources.
What is acceptable and what's not acceptable?
This is definitely an enforceable type of policy.
Some design considerations.
Should they be permitted to install software on their system?
Read copy files, not their own.
Modify files that you've read and access to but do not own.
With all of these policy requirements, they're then implemented through physical
controls, technical controls, or administrative controls.
User account policy.
User account policy defines the creation
process of user accounts, including user rights and responsibilities.
This is a big one.
Since accounts are used to grant access and accounts are used to apply special
permissions, privileges, and so forth, whoever is allowed to create accounts has
a pretty serious ability or power that should definitely be monitored.
So who's allowed to create user accounts?
Account creation or group membership changes.
That's definitely something that should be
audited on a Windows system or any other system.
Divines of creation process user accounts,
rights and responsibilities, who has the authority to approve account requests,
who are permitted to use the competing resources, can users have multiple
accounts on a single system, can you share accounts, etc.
Remote access policy, also a big deal.
The principle of least privilege just
defines that you only have what is necessary to do your job.
So if you do not require remote access, you don't get it.
The problem with remote access is it provides remote access.
So that could be exploited by an attacker trying to dial into the corporate
environment or VPN in with a captured set of credentials.
So again, if it's not needed, shut it off.
But who has allowed remote access?
What methods does the company support?
Dial out modems allowed in the internal network.
That's a bit dated.
Any extra requirements?
Mandatory antivirus, security software in the remote system, etc.
The information protection policy.
What are information sensitivity levels?
This deals with processing, storing, and transmitting sensitive information.
It deals with things like data classification, although quite often you
have a data classification policy that lays out what is top secret, what is
secret, what is confidential, what is sensitive and unclassified, what is
proprietary, what is public, what is private, etc.
What are the information sensitivity levels?
Who can access the sensitive information?
How is it stored and transmitted?
You need to protect your data at rest, in transit, and in use.
In RAM, on a fixed storage, or across a network communications medium.
Firewall management policy, also a pretty big deal.
Firewall management management is...
Well, firewall is the gatekeeper between
your environment and the outside world, the Wild Wild West of the internet.
So firewall management policy dictates what's allowed in and out of the network.
That's a big deal.
Design considerations, who has access to the firewall systems,
who can receive requests to make changes to the firewall configuration, who can
approve request to change firewall configuration, who can see the rules and
access list, who can see the policies, etc.
On a network connection policy, the
ability to install a device on the network, that's also a big deal.
If I can install a device in the network,
I can put a enemy system behind the front lines, behind enemy lines.
Iot devices, for example, can be
leveraged by an attacker through vulnerabilities and
software glitches and so forth, or just way too much functionality.
A lot of times we don't realize when we
put our Nest Doorbell on our front door and add it to our internal wireless
network, that we're providing access potentially to the outside world.
So installing new resources on the
network, installing new devices definitely needs to be controlled.
Business Partner Policy.
There's a lot of business models that outsource, have partnership relationships.
So when you're doing business with a
partner, you're going to be exchanging sensitive information.
How you do that needs to be secured.
It defines the agreements, guidelines, and
responsibilities for business partners to run business securely.
Is it mandatory for the company to have a written security policy?
Should each company have a firewall or other perimeter security device?
Man, I hope so.
How will one communicate?
Vpn over the Internet or least line.
How will access to the partner's resources be requested?
So you get together and you lay out specifically how we're going to interact.
The password policy.
Password policy, really important,
provides guidelines for using strong passwords for an organization's resources.
So you have things like password length,
complexity, password blacklist, duration, minimum and maximum ages, reuse
and history, complexity requirements and so forth are often built into the policy.
But the idea is that passwords need to be easy to remember, but difficult to guess
and can't be cracked in a reasonable time frame.
We'll definitely talk more about passwords later in the course.
Physical security policy.
Physical security is your first line of defense.
It defines guidelines to ensure adequate physical security measures are in place.
Is the building protection deficiency reviewed regularly?
Is there a process to identify outside
vendors, visitors, sorry, outsiders, visitors, contractors, vendors?
Are there adequate lighting systems in place?
Are entry points blocked? Badges keys?
We have a module on physical, so we're going to dig into this a lot more.
Is video surveillance monitored regularly?
Proper inventory of the organization's assets maintained regularly?
When physical, you also look at things like fire suppression.
Again, we're going to talk about a lot of that in the physical security module.
I'll hold off on further discussion of that until we get to the module.
Hard information system security policy.
All right, defines the guidelines to
safeguard the organization's information systems for malicious use.
This deals with things like anti malware. Is it updated regularly?
Is the OS patched?
Are we using strong password policies?
Are they secured with strong physical security policies?
Again, physical security is your first line of defense.
You can have all sorts of technical controls, but if I could walk up and steal
your system, that's a definite compromise of security and pretty easy.
I'll be able to pull the hard drive out,
hook it up to a system and access control list, mean nothing.
You bring your own device policy.
I haven't managed and been in a production
administration role for quite some time, over a decade.
But if I was to go back into production, network administration, and I had to
manage users, bring their own device, that might keep me up a little bit at night.
What exactly are they allowed to do with the device?
What do they have access to?
What types of policies are enforced on the device?
But with BYOD, we're allowing employees to
use their own tablets, smartphones, computers, etc.
Set guidelines to maximize personal benefits and minimize risks while using
employee's personal device and organization's network.
What are your immediate concerns with personal devices?
How well are you securing them?
What software you're running on them?
What websites are you visiting with that device?
Are your kids using it, etc.
Design considerations, what devices are allowed, what resources can be accessed,
what features need to be disabled, where the data storage considerations,
what security measures are required for data and BYOD devices.
Your software or application security policy.
Your application policy mandates proper
measures to enhance the security of inhouse and purchased authentication.
Design considerations,
configuration management, authentication, error handling.
We're going to talk about most of this in
later discussions, but just a couple of quick examples.
Error handling and exception management.
An application that gives too detailed error messages gives away a lot about the
structure of the application and possibly your infrastructure.
Data protection and storage in transit.
You need to encrypt the data in use in transit or at rest.
User and session management.
We talked about a little bit already about session hijacking, session replay attacks,
data validation, authorization, encryption.
Your data backup policy.
Your backup policy really important, often neglected.
It helps an organization recover
and safeguard information in the event of a security incident or network failure.
When you don't have an appropriate backup
policy and you lose your data, you may not be able to restore to the
correct recovery point objective or within the required time objectives.
But backups need to be tested periodically to be sure you can actually restore them.
They're definitely a consideration in your
disaster recovery and business continuity planning.
Design considerations, location of the backup, who can access backups because the
backups are the same sensitivity as live data.
Backup schedule, type of backup used,
hardware and software requirements for taking backups.
A data retention policy.
Don't retain anything for longer than is necessary, period.
Otherwise, you're incurring risk and
you're liable potentially if that data is compromised.
So adhere to applicable laws, regulations, policies, rules and acts,
types of data to be included, name and contact personnel, record retention
schedule, all things to consider in your data retention policy.
Our internet usage policy.
Is it possible that your employees are
accessing sites other than sites required to do their job at work?
Most definitely.
The internet usage policy governs the way
an organization's internet connection is used by every device in the network.
Usage limit for official as well as
personal use, time frames, method adoption for web usage monitoring, levels of
privacy for employees, restricted content, inappropriate sites, etc.
All goes into your internet usage policy.
User access control policy gives the
organization the ability to control, restrict, monitor, and protect corporate
resource availability, integrity, and confidentiality.
Design considerations.
Who can access, what system resources can be accessed?
What files can be read?
How to share data with other entities?
What programs can be executed?
Our to Privilege management policy helps
organizations decide what users can and cannot do.
So a couple of things to consider and include are provisions for separation of
duties, which again is the sharing of responsibility for tasks related to a
particular security process amongst multiple people within the organization.
We talked about separation of duties.
There's the concept of dual control and split knowledge.
Dual control would be it requires two
entities to perform an operation like two keys to launch a missile.
Or split knowledge would be something along the lines of one entity has one half
of the safe combination, one has another, two signatures on a check.
Also, different job role specifications.
That term can apply to a couple of different definitions.
The separation of duties.
A software programmer shouldn't be able to put software into production.
You shouldn't have the one network
administrator doing everything database administration and so forth.
So a couple of different definitions of separation of duties.
The main goal is to control frauds,
insider attacks, data breaches, abuse, theft, and errors.
Minimal privileges.
Everybody all together now.
How much privilege should I have?
Only enough to do your job. Perfect.
Ensures that users are granted only the
privileges necessary to fulfill their job roles.
And that means regular audits of the
accounts to ensure that everybody has just enough access to do their job.
Ensures confidential data doesn't fall in
the wrong hands when at least privilege account is compromised.
Then job rotation, we haven't really mentioned that yet.
Job rotations and mandatory vacations
serve detective and deterrent types of functionality or purposes.
In job rotation, if your job role is
rotated into periodically, you might think twice about committing fraud or if you're
the accountant, for example, and I'm skimming off the top, if I know next week
somebody else is going to rotate into keeping the books, then I know I'm going
to get caught and I probably won't do it to begin with.
But it also gives you depth in each position.
So for example, if I was incapacitated for whatever reason and I'm
keeping the books, then somebody else can take over the next week and it gives you
depth into various positions, also detection of fraud and deterrence.
An offboarding policy.
Onboarding is the initial account creation, identity verification, group
membership, population, security awareness, education, training, etc.
Providing access.
Offboarding is exactly the opposite of that.
It's removing access when an employee is no longer going to be at the organization,
which in some situations that is an unfriendly event.
You might have a disgruntled employee that
might desire to do some damage to the organization.
If they're getting fired, let go or whatever, passed over for promotion,
whatever the case may be, there might be an extra grind.
So you want to reduce or minimize the chances of that actually happening.
So you should disable the user account,
all other credentials, ensure that the handover of all assets and hardware and
software are under the control of the existing employee ID badges, keys, etc.
Uninstall and delete all the applications and data belonging to the organization and
ensure the credentials for access in the network are changed, especially when the
existing employee is from a secure admin t o.
Account audit policies.
The account audit policy defines the type
of user actions or events to be recorded in security logs.
An effective audit policy will lay out specifically what types of events to
monitor, and then you actually have to go back and review the audit logs.
To identify potential security issues in
advance, ensure accountability, provide evidence in the case of a data breach.
Design considerations.
How to collect, store and analyze audit data.
Test the audit policy before deploying it in the production environment.
Consider the amount of storage required
for the audit data, and then determining exactly which types of events to audit.
Account Restriction Policy.
Restriction Policy is implemented to grant permissions or restrict users by
considering certain parameters like location and time.
Location based Restriction, based on where I am.
Geolocations, IP addresses, geo fencing, which is virtual perimeter Restriction,
accepting or declining service request depending on location.
So based on your physical proximity, I can allow or dis allow access.
In time based restriction, that's working hours.
Used to restrict connections or sessions for a specific amount of time.
Create specific access hours.
Set the maximum of time for which an account can access resources.
So duration and schedule.
Our third party risk management policy.
Suppliers and vendors, cloud providers, things like that.
Third party risk management helps the
organization in assessing and identifying suppliers vulnerable to cyber attacks,
defining the necessary controls to mitigate the identified vulnerabilities.
So things to consider.
Service level agreements with third party providers, list
of compliance regulations for the vendor, acceptable vendor controls,
agreement to terminate the contractor service if any of the security measures
are not satisfied, maintaining disaster recovery and business continuity,
and perform third party screening before providing network access.
Organizational policies and asset management policy.
It involves developing an appropriate strategy that includes actions to be taken
to protect and preserve the integrity of IT assets. All right, so we've defined
integrity, protecting against unauthorized modification.
Also, I would throw confidentiality in there as well.
But the design considerations, what are the primary objectives?
What are the risks and threats associated with asset management?
Supportive executive officials required
for planning and enforcement, what resources are available?
What are the probable cost expected for the management of IT assets?
Change management policy, really important.
Change has to happen.
An organization is not changing its diet.
Change is going to happen, but change
should occur in an orderly fashion and it should be tested, plain and simple.
I can tell you numerous stories about a
quick fix that ended up causing a huge security issue later, specifically
around opening ports on firewalls and that thing.
The request for the change is made.
The ramifications of the change are
considered, it's tested, it's deployed, you updated version control, etc.
But the whole purpose of change management is to ensure that it happens in an orderly
fashion and to prevent a security compromise.
Change management will help minimize the disruption of services
while implementing changes following standard change procedures.
There should be request form.
It should be approved by an advisory board, an entity or entities that
determine allowable or dis allowable changes.
And again, ultimately, the decision is that of management, they're going to
delegate that responsibility down to an advisory board.
Our changes should be tested huge in a staged environment.
Roll back plan.
What happens if a flaw is discovered after roll out and we
have to roll it back, you should have a revert plan.
Perform post change test and documentation
to ensure whether the change is successful.