128 A Practical Guide to Security Assessments
the process flow and look at where the various technologies fit into the
process. One of the dangers when determining the critical technology is
that there is a tendency to just focus on a particular area. It is important
to look at all of the technologies that make the process work because a
failure in any one component could potentially bring down the process
or cause a security breach.
• Who is responsible for managing the supporting technology? — The
purpose of this question is to determine whether someone owns the tech-
nology — i.e., is someone charged with the responsibility of ensuring that
the technology is working as intended? For example, are there system
administrators in charge of administering the servers or application owners
who have responsibility for the application? If ownership is lacking, it
should raise a red flag immediately because a potential lack of account-
ability is present.
• If the supporting technology was unavailable and this business process
could not occur, what are the impacts related to revenue, legal, or regu-
latory concerns, reputation damage, or any other impacts? — This ques-
tion will give you a good feel for how important the different pieces of
technology are. The level of security required for the technology is based
on how critical the technology is to the business process. If you discover
a security weakness with the technology, this information related to busi-
ness impact will influence your recommendation. For example, assume
that you discovered security vulnerability on a server. Your recommenda-
tion to fix the vulnerability might be different based on the potential
impact — e.g., there is a big difference between the impact being some
users not being able to log on and the impact being that the company
might not be in compliance with a regulation that can result in fines.
• What is the tolerable downtime? — Tolerable downtime is the amount of
time that systems or processes can be down and the company can tolerate
it. It is after the tolerable downtime that companies begin to “feel the
pain.” At what point does the downtime really affect someone’s ability to
do his or her job? The answer to this question will give a sense of the
criticality of the process (similar to the previous question). Tolerable
downtime will also influence some of the recommendations you make.
When analyzing the tolerable downtime, keep in mind that it might vary
based on when it occurs. At some times during the year or even at
particular times during the day, the tolerable downtimes might be different.
For organizations that are cyclical in nature such as universities, tolerable
downtime varies based on the time of year (i.e., the tolerable downtimes
for systems during the beginning of a semester and the period when
prospective student applications are being processed are lower than other
times). Another example is typical for-profit companies, which have a
financial closing at the end of the month. During the one to two weeks
when the financial closing activities are taking place and companies are
trying to meet financial reporting deadlines, the tolerable downtime is
significantly less than during the rest of the month.
AU1706_book.fm Page 128 Tuesday, August 17, 2004 11:02 AM
Initial Information Gathering 129
• Are there any manual or other workarounds that can be done while the
technology is unavailable? For how long can the workaround be done? —
This is related to the previous question on the tolerable downtimes because
workarounds must be considered if technology is unavailable. Whether
some workaround exists can have a significant impact when determining
the risk and recommendations. A good workaround can potentially change
a high-priority risk to a medium- or low-priority risk simply because if
the technology is not available, there is still a way to get the job done.
As will be discussed later, the recommendations must reflect the associ-
ated risk and be as cost effective as possible.
• What critical data is generated as a result of this process and where does
it reside? — In any critical process, critical data is probably generated.
Information regarding where critical data resides will be important to
know when you begin to determine what systems are critical and will be
reviewed in detail.
Integration Points with Other Departments
Integration points with other departments are instances where different departments
work together as part of a business process. Different departments working together
can range from a simple verbal information exchange to different systems commu-
nicating together. Integration points are important to understand because it is at these
points where processes do not always work. Roles and responsibilities are not always
clear because everyone has a different idea of who is doing what. In some cases
you might find that no one owns a specific task because everyone thinks someone
else is responsible. Some of the typical areas to consider when evaluating the
integration points between departments are listed below:
• Dependencies between departments — One key area to look at with critical
business processes is dependencies that can be single points of failure.
Dependencies may include providing information for a transaction, being
another step in a process that spans many departments, or in general any
process where there is a dependency between different groups. One exam-
ple of dependencies between departments as it pertains to a business
process, which is prevalent in companies today, is user terminations. When
an employee leaves a company, many companies do not have a good
process for ensuring that all relevant parties know that someone is leaving
the company. The IT department, which is responsible for removing the
employee’s network access, is often the last to know. Application owners
who are responsible for application-level access are often never told. In
addition, often no method exists of definitively knowing what company
assets the person might have. An overall lack of communication between
groups and a lack of ownership of key parts of the process are present.
In this process, there are dependencies on all the departments to commu-
nicate with each other to ensure that terminations are handled properly.
Significant risks may occur if terminations are not handled properly (See
AU1706_book.fm Page 129 Tuesday, August 17, 2004 11:02 AM
130 A Practical Guide to Security Assessments
Employee Terminations Questionnaire in Appendix I), and a single point
of failure can result in a significant security incident.
• System integration and determination of single points of failure — Dif-
ferent departments might have different systems, which might exchange
information. The security implications of the integration of the two sys-
tems should be reviewed. Some of these implications can include ensuring
the integrity of information and reviewing people’s level of access. An
example is the creation of financial statements in some companies. Where
no enterprise-type system is in place, financial statements might be created
by having a general ledger system obtain information from other systems
that record specific functions — e.g., accounts receivable, accounts pay-
able. For the creation of the monthly or quarterly financial statements, the
integrity of the data from the legacy systems must be accurate. In light
of some recent scandals, companies (publicly traded) have a vested interest
in ensuring that their financial statements are accurate. Another example
that you might see on the infrastructure security side relates to Internet
connectivity. Take the case of a company that is dependent on Internet
connectivity as part of a critical business process. This company might
have all inbound and outbound traffic to and from the Internet go through
a single firewall. The firewall is a single point of failure because if it goes
down, no Internet connectivity is possible. As part of the security assess-
ment, it would certainly be appropriate to ask what type of redundancy
the company has for the firewall.
• Transmission of information — The transmission of information can have
significant implications depending on the nature of the information. With
this question, you need to determine where information transmission needs
to be secured. In particular, the transmissions of sensitive information such
as personally identifiable information, sensitive employee-related informa-
tion, certain operations-related information, competitive proprietary infor-
mation, and other information could have security implications. These
security implications can affect the business from a legal or operational
perspective as well as damage the reputation of the company. For example,
when employees face some kind of disciplinary action, managers might
send sensitive information about the person over electronic mail to human
resources. Someone who is technically savvy can potentially intercept this
information, which can result in potential legal problems for the company.
Past Security Incidents
Past security incidents are very useful to know about because they demonstrate
potential security weaknesses. Also, past security incidents are hard evidence about
how a company reacted to the security incident and how severe the impact was. If
the client had any security incidents recently, below are some questions to ask
regarding them:
• What was the nature of the security incident? The nature of the security
incident will probably highlight some area of weakness from a security
AU1706_book.fm Page 130 Tuesday, August 17, 2004 11:02 AM
Initial Information Gathering 131
perspective. For example, a disgruntled employee who was terminated
but who still had certain access to systems because his access was not
properly terminated could have caused the incident. This issue could lead
to findings in the areas of how terminations are handled and general user
ID administration, if these topics were not addressed after the incident.
• How soon did you become aware of the incident? Did you find out because
of a documented process or by accident (e.g., happened to be talking to
somebody)? How soon the client became aware of the incident is an
indication of whether the company has proper mechanisms in place to
find out about security incidents. “Proper mechanisms” can refer to
employees being aware enough to alert the right people or having the
right systems in place to alert the company to incidents. During the
security assessment, if you ask whether the client has had a security
incident and the response is “no,” the next question is “how do you know?”
For many companies, no mechanism is in place to ensure knowledge that
an incident had occurred. Although security incidents can occur with any
company, how quickly the incident is detected can make a big difference.
Good detection methods and a strong incident response process can sig-
nificantly reduce the damage resulting from an incident. A perfect example
is Web site defacement. Some companies will know immediately, but
other companies will find out about it by accident. How quickly the Web
site can be fixed can make a big difference in the impact of the defacement.
• What was the reaction? Once the incident occurred and the client found
out about it, did all the people involved understand what they needed to
do in reacting to it? Questions related to whether proper communication
took place, whether the right people were involved in restoring systems,
and a host of other items (which are covered in the Incident Response
checklist) should be asked. If the reaction was less than adequate, a weak
incident response process should be flagged as an issue.
• What was the impact of the incident? The impact of the incident provides
empirical evidence of what the true risk of an incident is. It can help you
quantify the impact, which is important because it helps determine cost-
effective steps for mitigation that are commensurate with the risk. For
example, if an incident occurs where a business-to-consumer Web site is
taken down, you can quantify the immediate impact related to revenue
and the long-term impact related to a loss of customers. Here, you can
look at the real impact related to an incident and how it affected the
business, which will be helpful when doing the risk analysis.
• What has been done to prevent such incidents from happening in the
future? With any security incident, companies should at least go through
the process of assessing what happened and determining whether any
additional security measures should be taken to prevent it from happening
again. Whether or not management does anything gives some indication
about management’s attitude about security. If nothing was done, there is
a chance that management did an analysis and determined that there were
no measures to take that were cost effective. It could also mean that they
AU1706_book.fm Page 131 Tuesday, August 17, 2004 11:02 AM
132 A Practical Guide to Security Assessments
just did not do anything about it. As part of the security assessment, you
should find out about this, as it will potentially lead to a finding. The
answer to this question may also result in recommendations related to
deploying new technologies such as intrusion detection systems or addi-
tional security-related procedures.
Planned Initiatives
A critical component of a security assessment is to determine what steps need to be
taken long term to secure the company’s processes and related environment. To
determine long-term information security recommendations, you have to know what
kind of initiatives the company is planning for the future. Initiatives can vary from
company to company and can include such things as:
•Offering services via the Internet — e.g., e-commerce, content — See
Business-to-Business and Business-to-Commerce questionnaires in
Appendices K and L.
• Change in location.
• Outsourcing processes or technology — See Managed Security question-
naire in Appendix O.
• Use of Application Service Providers for key business processes — See
Externally Hosted Services questionnaire in Appendix G.
• Deployment of a major application.
•Will the company be required to comply with certain regulations in the
future (HIPAA, GLBA, etc.)? — See HIPAA questionnaire in Appendix Q.
The initiatives listed above are common initiatives for companies. For each of these
initiatives, specific questions can be asked. In some cases, questionnaires in the
Appendices can help you develop specific questions.
Other Interviewee-Specific Questions
This section is for any questions that you have developed as a result of your
knowledge of the company. It is based on the initial research you have done so far
and the questionnaire that was discussed with the client. These questions in this area
will be added in the next phase — business process review — when the question
sets are finalized.
TRADITIONAL SECURITY-RELATED QUESTIONS
The other major area of the generic questionnaire for business process owners is
traditional security-related processes that affect or involve them. Some of these topics
might have been discussed during the business process discussion. To the extent that
they have not been discussed, this is the time to address them.
Listed below are traditional areas of security that are relevant for most employ-
ees. Most of the topics listed below are addressed in ISO 17799 (the Information
Security best practice standard). For each of the topics listed below, most employees
have some involvement in them. Although a good majority of the tasks related to
AU1706_book.fm Page 132 Tuesday, August 17, 2004 11:02 AM
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.