Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
0% found this document useful (0 votes)
60 views

Analyzing and Securing Data

An examination of the security risks faced by a fictional organization and the proper approach needed in order to secure their data.

Uploaded by

Amir Muhawesh
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
60 views

Analyzing and Securing Data

An examination of the security risks faced by a fictional organization and the proper approach needed in order to secure their data.

Uploaded by

Amir Muhawesh
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 14

ITS

SERVIC
ES

SEIS 661

Analyzing and
securing data in a risk
ridden world

Amir
Muhawesh

Introduction
Any company wishing to do business in todays information driven world will at one point
or another find itself facing questions of information security and what role it should play in day
to day operations, It would be easy to tie down the hatches and take an all in approach, simply
securing all data to every extent possible, to hire the best consultants, and to ensure every
domain is covered in all aspects. Ten, even five years ago this approach would seem silly, even
a waste, as information security was something that was an expense, not an asset. In the last
few years however, the NSA, Target, Google have given the public a startling slap in the face
and the given the topic of information security a scrutiny it has never seen.
It is not the public that finds itself obligated to react; however, it is the organizations that
are in the cross hairs of both those with ill intent and those concerned about their safety and
privacy. In light of this new scrutiny, organizations can tend to over correct in hopes of protecting
themselves and their images. The result is wasted resources and little hope of ever achieving a
balance between real security and the companies interests. It is this same scrutiny that has
changed the view on security from that of on obligation to being an asset, something to gloat
about, which only inflames the issue of over correcting. The result may indeed be more harmful
than a lack of response in the first place. Wasted resources, misallocated funds, a false sense
of security, these things all make it that much more important to understand where the real risks
lie and what controls are needed to properly mitigate them.

Approach
A quick examination of the situation we are put in quickly reveals two major problems to
be overcome. First, what approach are we going to use to protect ourselves, our clients, and our
interests? Second, how are we going to make this possible on a limited budget with limited
time?
To make this possible, we find that it is necessary to create a targeted approach,
investing in only the domains crucial for the operation and growth of the business, at which point
further resources can be put into information security.
It is only logical then, to put our resources into domains which have the strongest for
clearest benefit for us, and protect our most valuable asset, our data. We believe starting with
our data and working our way out from there will allow us to build a strong security policy that
starts with the most important aspect of our business and can organically grow from there. To
put it simply, we are taking a data-centric approach to our information security.

Security Concern Number One: Proper Classification of Data


Problem Statement
Currently our data, which can be considered our bread and butter, is unclassified and
homogeneous. In order to strike the proper balance between security and usability, we must first
define, classify and prioritize our data. Without doing so, we will be unable to properly manage
our resources and make sure that they are allocated in a balanced and logical way. We dont
want to expend excessive resources guarding data that does not need protection, and
conversely, we cannot afford to leave critical and sensitive data unguarded and vulnerable.
Knowing our data well and classifying it properly is the crucial first step before we can move
forward with any of our other security domains in a sensible manner.

Risks and Issues


Without proper classification of our data, any other security implemented, no matter how
well designed or implemented is essentially useless. For example, if we implement a state of the
art physical security program in which only authorized employees are allowed into our office, the
effectiveness of this program will become null, as all employees would have access to all data
at all times, putting our data at great risk from internal threats, malicious intent, and even
heedless employees.

Recommendation
Any company operating correctly is going to have at least two or three layers of
classification, their public data, sensitive data, and private data. Companies that offer products
that do not gather or otherwise encapsulate sensitive client data would fall into these categories.
An example is a company that sells widgets. The public data would be data about the company
that is easily accessible to anyone who sought it out. Sensitive data would regard internal
matters of the company such as salaries, profits and other commercially related data. Private
data would simply be data kept internally regarding employees that are used for day to day
operations within the company. Because that company does not need to gather PII (Personally
Identifying Information), it has no need to classify data into the confidential level.
ITS services, however, does not have this luxury. Since we are in the lucrative field of
asset management, we hold the responsibility of protecting the most confidential data possible.
Things like social security numbers, bank account numbers, financial transactions, and tax data
are all our responsibility to keep safe. This requires careful classification of our data, which will
2

allow us craft our policies, standards, and guidelines to ensure responsible handling of client
data.
Following this chain of thought, our first recommendation is going to be to classify the data into
the four aforementioned categories.
Classification
Public

Sensitive

Private

Confidential

Definition
Information that has been
declared public knowledge
by someone with the
authority to do so, and
can freely be given to
anyone without any
possible damage.
Privileged or proprietary
information, not
accessible to everyone.
Sensitive data requires
extra scrutiny for
completion and accuracy.
Information for use
exclusively within the
organization. Harm to the
organization or individuals
within the organization
could possibly occur if this
information is obtained
through unauthorized
access.
Data used exclusively
within the organization
and to privileged
individuals only.
Unauthorized access by
individuals within or
outside the organization
would cause harm to both
the organization and its
clients including but not
limited to the reputation
of the organization.

Example
Project data, currently
released product info and
pricing etc

Financials for the


organization, client lists,
future earnings forecasts
and planned product
launches
Data about employees,
executives, HR
information

Transactional information
of client accounts, PII of
both clients and
employees, account
numbers.

Domain
3

Data Classification falls under, and partially covers the domain of Information Security
Governance and Risk Management.
Now that we have classified our data, we have laid the foundation to create our policies,
guidelines, and standards not only for the safe handling of our data but for our entire security
policy as well. The above classification allows us to create the following policy which will be
used as a guide companywide in for the safe handling of data.
Information Sensitivity Policy
Purpose
The Information Sensitivity Policy is intended to help employees determine what
information can be disclosed to non-employees, as well as the relative sensitivity of
information that should not be disclosed outside of ITS services without proper
authorization.
The information covered in these guidelines includes, but is not limited to,
information that is either stored or shared via any means. This includes: electronic
information, information on paper, and information shared orally or visually (such as
telephone and video conferencing). All employees should familiarize themselves
with the information labeling and handling guidelines that follow. It should be noted
that the sensitivity level definitions were created as guidelines and to emphasize
common sense steps that you can take to protect ITS services confidential
information. Please Note: The impact of these guidelines on daily activity should be
minimal.
Questions about the proper classification of a specific piece of information should be
addressed to your manager. Questions about these guidelines should be addressed
to Information security.
Scope
All ITS Services information is categorized into four main classifications:
Public - Information that has been declared public knowledge by someone with the
authority to do so, and can freely be given to anyone without any possible damage
to ITS Services.
Sensitive - Privileged or proprietary information, not accessible to everyone, it is
data which requires extra scrutiny for completion and accuracy.
Private - Information for use exclusively within the organization. Harm to the
organization or individuals within the organization could possibly occur if this
information is obtained through unauthorized access.

Confidential - Data used exclusively within the organization and to privileged


individuals only. Unauthorized access by individuals within or outside the
organization would cause harm to both the organization and its clients including but
not limited to the reputation of the organization.
Confidential is assumed to contain all other information, it is a continuum, in that it
is understood that some information is more sensitive than other information, and
should be protected in a more secure manner. Included is information that should be
protected very closely, such as trade secrets, development programs, potential
acquisition targets, and other information integral to the success of our company.
A subset of confidential information is "Third Party Confidential" information. This is
confidential information belonging or pertaining to another corporation which has
been entrusted to ITS Services by that company under non-disclosure agreements
and other contracts. Examples of this type of information include everything from
joint development efforts to vendor lists, customer orders, and supplier information.
Information in this category ranges from extremely sensitive to information about
the fact that we've connected a supplier / vendor into ITS Services network to
support our operations.
Policy
The Sensitivity Guidelines below provides details on how to protect information at
varying sensitivity levels. Use these guidelines as a reference only, as ITS Services
confidential information may necessitate more or less stringent measures of
protection depending upon the circumstances and the nature of the confidential
information in question.
Minimal Sensitivity: General corporate information; some personnel and technical
information Marking guidelines for information in hardcopy or electronic form.
Access: ITS Services employees, contractors, people with a business need to know.
Distribution within ITS Services: Standard interoffice mail approved electronic mail
and electronic file transmission methods.
Distribution: Outside of ITS Services internal mail: U.S. mail and other public or
private carriers approved electronic mail and electronic file transmission methods.
Electronic distribution: No restrictions except that it is sent to only approved
recipients.
Storage: Keep from view of unauthorized people; erase whiteboards, do not leave in
view on tabletop. Machines should be administered with security in mind. Protect
from loss; electronic information should have individual access controls where
possible and appropriate.
Disposal/Destruction: Deposit outdated paper information in specially marked
disposal bins on ITS Services premises; electronic data should be expunged/cleared.
5

Reliably erase or physically destroy media. Penalty for deliberate or inadvertent


disclosure: Up to and including termination, possible civil and/or criminal
prosecution to the full extent of the law.

More Sensitive: Business, financial, technical, and most personnel information


Access: ITS Services employees and non-employees with signed non-disclosure
agreements who have a business need to know.
Distribution: Within ITS Services: Standard interoffice mail approved electronic mail
and electronic file transmission methods. Distribution outside of ITS Services
internal mail: Sent via U.S. mail or approved private carriers. Electronic distribution:
No restrictions to approved recipients within ITS Services but should be encrypted or
sent via a private link to approved recipients outside of ITS Services premises.
Storage: Individual access controls are highly recommended for electronic
information.
Disposal/Destruction: In specially marked disposal bins on <Company Name>
premises; electronic data should be expunged/cleared. Reliably erase or physically
destroy media. Penalty for deliberate or inadvertent disclosure: Up to and including
termination, possible civil and/or criminal prosecution to the full extent of the law.
Most Sensitive: Trade secrets & marketing, operational, personnel, financial,
source code, & technical information integral to the success of our company.
Access: Only those individuals (ITS Services employees and non-employees)
designated with approved access and signed non-disclosure agreements.
Distribution: Within ITS Services Delivered direct - signature required, envelopes
stamped confidential, or approved electronic file transmission methods. Distribution
outside of ITS Services internal mail: Delivered direct; signature required; approved
private carriers. Electronic distribution: No restriction to approved recipients within
ITS Services, but it is highly recommended that all information be strongly
encrypted.
Storage: Individual access controls are very highly recommended for electronic
information. Physical security is generally used, and information should be stored in
a physically secured computer.
Disposal/Destruction: Strongly Encouraged: In specially marked disposal bins on ITS
Services premises; electronic data should be expunged/cleared. Reliably erase or
physically destroy media. Penalty for deliberate or inadvertent disclosure: Up to and
including termination, possible civil and/or criminal prosecution to the full extent of
the law.
6

Enforcement
Any employee found to have violated this policy may be subject to disciplinary
action, up to and including termination of employment.

Security Concern Number Two: Logical Access Controls


Problem Statement
Our data, which is now classified into four categories, remains unguarded. We currently
have no method of controlling the who, what, where why and when of accessing our data.
Because our data is now classified however, we can begin to build out proper controls to create
a reliable gateway to our data thereby guarding our most critical asset. Using the principle of
identification, authentication, authorization, and accountability we will implement a system that
ensures not only that the correct people are accessing our data, but that we have robust
auditing capabilities in case someone does ever go rogue.

Risks and Issues


When someone thinks of information security, access control is typically one of the first
things that will come to mind. This makes the risks and issues clear, and makes it easy to justify
implementation of controls to mitigate those risks. To put it simply, our biggest risk is having
unauthorized access to our data, whether from an internal or external threat. Specifically, our
risks follow the controls laid out by the logical access control model.
Our first risk and resulting first control is identification, or having someone falsely identify
them self as an entity or individual. Our next risk is authentication, where we run the risk of
someone gaining the ability to falsely authorize them self to gain access to our data. Despite the
apparent difficulty in doing this, this risk also poses the biggest threat, because if it is
successfully exploited, our other security measures will be rendered useless. Once a user has
properly cleared these first two steps in logical access control, we still have a risk of
authorization, essentially our third line of defense. Like data classification, without proper
authorization procedures, there is no use in implementing any procedures at all. Lastly we come
to accountability, which we could say is our last line of defense. The first three controls can be
considered preventative, while our accountability is a detective control. It serves the purpose of
7

both letting the employees know they will be held liable for their actions when accessing
sensitive data, and allows any interested parties to follow a story of what may have happened
after any incidents.

Recommendation
Building on our data classifications, we are going to implement logical access control to
ensure the confidentiality, integrity and availability of our data. To avoid expending resources
unnecessarily and over burdening our employees, public and sensitive data will be kept behind
one layer of defense. That is, employees will be allowed to keep this information directly on their
laptops, able to access it after entering a user-name and password to access their local
machines.
Private and confidential information will be kept exclusively on two separate severs
respectively. Access to these servers will require additional access and authorization which will
only be possible after employees have logged onto their virtual machines. This not only adds a
second layer of security, but allows the most sensitive data to remain safe in the case that a
laptop is stolen or misplaced.
Private information will be kept on a server which will require a traditional user-name, but
will also implement an RSA token in addition to a password. Once this information is properly
verified users will have unfettered access to data labeled as private.
Confidential information will be the most secure. Like private information, users will need
to enter an additional username and password along with a string provided by an RSA token.
Once they are on the server that hosts the confidential information, users will have to undergo
one last layer of defense. This will be implemented in the form of a dynamic password which will
be a minimum of fifteen characters and will change hourly. To access a system with confidential
data (such as logging in to a database directly) users will access a web based application that
allows the user to copy the current password by clicking a button. Although this may seem
excessive, it will allow users will not have to memorize the password, and changing hourly to a
random string provides strong protection against unauthorized access as well as prevent any
accidental privileges being left for former employees.
Audit logs will be kept for all logins and false login attempts. A monthly audit will be
conducted to review for suspicious activities such as multiple failed login attempts, cagey login
times, and unusual login locations.
Identification
8

Identification is perhaps one of the simpler controls to implement, but needs to be


scalable in order to allow for growth in a sustainable manner while keeping in consideration our
limited budget. Following the rules of identification laid out in the CISSP, the identifiers
(usernames) will be assigned using a standard naming procedure with each value being unique.
Authentication
Users are typically asked to provide something they know, have, or are. In order to
qualify as strong authentication, we must require two of three in order to qualify them as
authorized. For our first layer of access we will only require something they know (their
username and password). Moving to the second layer (private data) will require something they
have as well (RSA token) qualifying as strong authentication. Additionally, moving to confidential
information will also require the RSA token as well as the dynamic password.

Access
In order to ensure users are only getting access to the data level they are entitled to, we
are going to implement role based security. Each role will be attached to a group which allows
access to certain levels of data.
Audit
Audit logs will be kept for all logins and false login attempts. A monthly audit will be
conducted to review for suspicious activities such as multiple failed login attempts, login times,
and unusual login locations. Although seemingly inconspicuous, audit logs are vital to providing
details about any attempted or successful security breaches.

Domain
Logical access control falls under the domain of access control. Building upon the data
classification we have implemented from our first domain, we were able to strengthen our
security to qualify as strong authentication based of on four categories of data. Furthermore we
were able to ensure we have covered the four areas of logical access control which resulted in
preventive and detective measures to continue our data-centric approach to security.

Security Concern Number Three: Legal, Regulations, Investigations, and


Compliance
Problem Statement
Considering our limited budget and assuming a small window of time, our next priority
must be legal regulation if we want to operate as a legitimate financial company without risking
civil and criminal penalties and basically driving the company underground. We currently have
no idea of rules and regulations apply to our organization.

Risks and Issues


Due to our ignorance of the regulations that apply to a company like ours doing
business, we are running the risk of going out of business and being jailed essentially every day
we are in business. Clearly this is unacceptable and this risk needs to be mitigated. The
problem is twofold however. First, we are not fully aware of all laws and regulations that apply to
our business yet. Second, implementing them may not a simple one-off process in the same
manner classifying data or implementing logical access controls was. We can expect this to be
an ongoing process that may take place over the course of several years. As such, we can treat
the problem in the same way the previous two issues have been treated, instead we will have to
take a longer more drawn out approach.

Recommendation
A committee will be formed to investigate, analyze, and implement any relevant
regulation that applies to our organization. Ideally this committee would be as well rounded as
possible, but due to the limited resources of our organization we will need to form the committee
with just enough to show due diligence and due care to proactively relieve the company of
liability in case of both a data breach and in order to ensure the company becomes and remains
compliant to regulations that apply to it.
Our committee will consist of three individuals who will be responsible for analyzing,
planning and implementing whatever controls are necessary to gain compliance. The first
individual will be an executive who will bring the business perspective to the table. Budgeting,
long-term outlook, and organizational issues will belong to this individual. Second, we will have
a lawyer who is well versed in the regulation and law of information security especially in
regards to the financial industry. It will be this individuals job to interpret the law and guide us
down the path of compliance. The last individual will be a representative of the information

10

technology perspective, perhaps a CISO if resources allow, who will be in charge of the actual
implementation of any technologies and controls deemed necessary by the committee.

Head Start
Due to our training and the previous experience of the members of our committee, we
find that it is possible to gain a head start on path to compliance. Namely, there are two
looming regulations which are obvious in nature and demand immediate attention as their
implementation is mandatory and will take a significant amount of time to gain full compliance
with. The teams responsible for implementing the controls to be compliant will begin
immediately with these two regulations while our committee overseas progress and investigates
other laws and compliance that may deemed necessary.

Sarbanes-Oxley Act (SOX)


SOX compliance is well laid out, black and white regulation that makes a strong case for
a starting point towards regulation. We have in our favor the fact that the steps laid out and
qualifications to meet SOX compliance is clearly defined and laid out in Committee of
Sponsoring Organizations of the Tread-way Commission (COSO) model, which takes the
guesswork out of becoming compliant. It is important to note that although we are not a publicly
traded company, we must comply with SOX regulation if we are going to host data of any clients
that are publicly traded.

Gramm-Leach-Bliley Act of 1999 (GLBA)


The GLBA is the next regulation that screams out to be complied with, perhaps even
more so than SOX, because it applies specifically to financial institutions such as ours. This is
where our data classification becomes crucial and pays off, because the GLBA outlines
requirements regarding client data privacy, safeguarding, and pretexting. Our data classification
allows us to implement controls around only the specific data that the GLBA applies to, saving
us the time and resources that may have potentially been spent on applying controls to all of our
data even if it does not fall under the protection of the GLBA.

Domain
Complying to regulations and laws applicable to our organization appropriately falls
under the Legal, Regulations, Investigations, and Compliance domain. Unlike our first two
11

concerns listed, this concern is fairly well spread across most of the domain. By forming a
committee to research and investigate the laws and regulation needed to gain compliance, we
are ensuring that we cover our bases to protect both ourselves and our clients in terms of
existing regulation and any new regulation which may become law in the future.

Moving Forward
For the time being we find our current approach satisfactory in its requirement of
sufficiently securing our data in a manner that protects our organization, its clients, and allows
us to grow with the confidence to ensure clients of their safety and to appease regulators. As we
continue to grow we will find it necessary to utilize our increasing resources to continue our
data-centric approach and build out from there. Continuing with that theme, we will implement
the remaining domains prioritized by their proximity to our data, as resources become available
to do so.

References
Johnson, Cory. "What is Sensitive Information? - Definition from Techopedia."
Techopedias. N.p., n.d. Web. 5 May 2014.
<http://www.techopedia.com/definition/25260/sensitive-information>.
Kyriazoglou, John . "INFORMATION SENSITIVITY POLICY." . N.p., 13 Nov. 2011. Web. 5
May 2014.
<http://businessmanagementcontrols.blogspot.com/2011/11/information-sensitivitypolicy.html>.
"Role Based Access Control (RBAC) and Role Based Security." Role Based Access
Control and Role Based Security. National Institute of Standards and Technology, 3
Apr. 2013. Web. 5 May 2014. <http://csrc.nist.gov/groups/SNS/rbac/>.
Harris, Shon, and Polisetty Veera Subrahmanya Kumar. CISSP all-in-one exam guide,
sixth edition. 6th ed. New York: McGraw-Hill, 2013. Print.
"Information Security Policy Templates." SANS:. Sans Institute, n.d. Web. 5 May
2014. <http://www.sans.org/security-resources/policies/>.
"Financial Institutions and Customer Information: Complying with the Safeguards
Rule | BCP Business Center." Financial Institutions and Customer Information:
Complying with the Safeguards Rule | BCP Business Center. United States
Government, 1 Apr. 2006. Web. 5 May 2014.

12

<http://www.business.ftc.gov/documents/bus54-financial-institutions-and-customerinformation-complying-safeguards-rule>.
Bilger, Mike, Luke OConnor, Matthias Schunter, Morton Swimmer, and Nev Zunic.
"Data-centric security." IBM Global Services, 1 Dec. 2006. Web. 5 May 2014.
<http://www-935.ibm.com/services/no/cio/risk/gov_wp_data_centric.pdf>.

13

You might also like