108 ◾ Official (ISC)
2
® Guide to the ISSMP® CBK®
© 2011 by Taylor & Francis Group, LLC
System Hardening
In addition to the previously mentioned operating system hardening that applies to
all systems, Web servers have some specic hardening that can be done to increase
security. Some of the specics depend on what Web server software you are run-
ning, but they all have some aspects in common.
In addition to carrying out these initial hardening eorts, it’s also important
that the server conguration be kept up to date as new threats or security aws are
discovered. Any failover or redundant servers must also be examined to ensure they
are as secure as the primary server. System hardening is all about decreasing the
potential attack surface.
Some of the important questions to ask about the hardening of each Web server
the project will use are as follows:
◾ What applications or utilities are installed by default that can be uninstalled
or disabled without jeopardizing the project?
◾ What protocols or functionality can be uninstalled or disabled without jeop-
ardizing the project?
◾ Are there company policies or procedures for reinstalling or activating appli-
cations or utilities, and how are they enforced?
◾ Are there company policies or procedures for installing or enabling protocols
or functionality, and how are they enforced?
◾ What logging is in place to record changes in server conguration and soft-
ware settings, and what process is in place to audit these logs?
◾ Does this Web server share duties as any other type of server or domain
controller, and can it be moved to being a single purpose server to allow for
more security?
◾ What logging is in place to record server activity and access attempts, and
what process is in place to audit these logs?
◾ Are applications and Web services congured to run under least privileges?
◾ Does the project share this Web server with any other applications, Web sites,
or Web services and, if so, do they have security concerns that can jeopardize
the project’s security?
◾ What remote access is required for the project, and who requires this access?
◾ What logging is in place to record remote access and remote access attempts,
and what process is in place to audit these logs?
Access Control
As in any server environment, access control is a key security issue and requires a
close look. On top of the access control questions previously mentioned, there are
some access issues specic to servers and Web servers that need to be taken into
account. Some important questions to ask about access control for each Web server
the project will use are as follows:
Enterprise-Wide Systems Development Security ◾ 109
© 2011 by Taylor & Francis Group, LLC
◾ Who requires access to the server for project-related job functions, and what
kind of access do they require?
◾ Who requires access to the server for nonproject-related job functions, and
what level of access do they require?
◾ What applications require access to the server for project-related purposes,
and what level of access do they require?
◾ What applications require access to the server for nonproject-related pur-
poses, and what level of access do they require?
◾ What policy is in place regarding requesting, granting, and removing access
rights to this server, and how is it enforced?
◾ What logging is in place to record access changes, and what is the process for
auditing these logs?
◾ What logging is in place to record access and access attempts for the server,
and what process is in place to audit these logs?
Maintenance Plan
Maintenance, in various forms, is required to keep the Web server running and
secure. e constantly changing landscape of security means that ongoing main-
tenance, auditing, and security steps are needed to prevent a compromise of
the server.
Auditing—Auditing must be conducted on an ongoing basis to detect potential
security risks and undetected security-related events, and to ensure that existing
policies are being enforced. In order to conduct eective auditing, logging and
records must be kept, preferably in a secure location that is not on the actual server.
Someone must be responsible for reviewing these logs, and there must be a policy
in place of what to do if security-related issues are found.
Some of the important questions to ask about auditing each Web server the
project will use are as follows:
◾ What logging is done of server-level events like access attempts, etc., and
what process is in place to audit these logs?
◾ What logging is done of network events that may be aimed at the server or a
database or a resource it uses, and what process is in place to audit these logs?
◾ What corporate policy is in place for the review and auditing of all logs pro-
duced by the server for security-related issues, and who is in charge of doing it?
◾ What policy is in place to ensure that the party or parties that will be audit-
ing the logs is not likely to be a source of logged security violations, and how
is that enforced?
◾ What actions must take place or who must be notied if a security-related
event is detected during an audit?
110 ◾ Official (ISC)
2
® Guide to the ISSMP® CBK®
© 2011 by Taylor & Francis Group, LLC
Patches and Updates—Regular patching of the Web server software and the
Web server itself provides increased security by keeping up to date on manufacturer-
provided xes for discovered defects, including security defects. Updating of the
security software will ensure that the server has the latest signatures and detections
available.
Some of the issues listed below may seem unrelated to security on the surface,
but since patches and updates are vital for security, it’s necessary to know quite a bit
about the processes and policies around them.
Some important questions to ask about patches and updates to each Web server
the project will use are as follows:
◾ Who is or will be responsible for applying patches and updates to the server
and Web server software, and how is this enforced?
◾ What are the ramications of the server having to be rebooted or taken oine
to apply patches or updates?
◾ Are there company policies or guidelines for patches and updates that would
apply to the server, and how is this enforced?
◾ Is there auditing or enforcement of update and patch policies that would apply
to the server?
◾ Is there a requirement to failover to a redundant database or server during a
patch or update to ensure minimal downtime?
Other Applications
Application security can be a signicant source of potential risk and uncertainty,
due in part to the large number of variables in play.
Applications, in this case, are intended to span not only the external software
the company may purchase but also internal software.
is is not a case where you will be able to, or even should, examine every possi-
ble application or combination of applications for security, as that would take years.
Instead, it is valuable to develop a sense for the inherent risk based on the policies
for applications and applications development. A very controlled environment will
tend to lead to an overall reduction of risk, while a very loose or lax environment
will tend to lead to an overall increase of risk.
External Applications
One of the biggest variables is the sheer variety of applications users can and will
install, given the ability to do so. It’s quite common for users to innocently download
a piece of software because they saw or heard about it. at piece of software may be
legitimate or not, but each one introduces a set of unknown security risks to not only
the user’s system, but also to the network and maybe the company as a whole.
Enterprise-Wide Systems Development Security ◾ 111
© 2011 by Taylor & Francis Group, LLC
Users are also prone to opening or installing les sent to them via applications
like instant messenger systems or e-mail, which can lead to even further risks.
External applications fall into two major groups: commercial software and
shareware/freeware software. For this purpose, commercial software includes open-
source initiative software. Both commercial and open-source initiative software
have risks, but if the software is from a legitimate company, it usually has the
advantage of a manufacturer that is interested in security testing its software and
improving its security via updates or patches.
Shareware/freeware tends to be a complete unknown. Some shareware/freeware
is very well written, but some is not suitable for any kind of secure environment.
Security in this area may be somewhat light overall because the risks are not
judged to be high enough to justify the high cost of a very controlled environment
and attempting to enforce that control on all users.
Some of the important questions to ask about external software coexisting with
the project are as follows:
◾ What policies are in place governing what software users are allowed to
download and install, and how are those policies enforced?
◾ What policies are in place governing what commercial software users are
required to have installed, and how are those policies enforced?
◾ What policies are in place governing updating and patching commercial soft-
ware, and how are those policies enforced?
◾ What policies are in place governing whether users can exchange les with
external sources, and how are those policies enforced?
◾ What policies are in place governing scanning of systems and servers for
security risks and issues and reporting those issues to determine what action
should be taken?
◾ Do external applications have to pass any acceptance or approval process, and
who is responsible for running this process and what are its criteria?
◾ What logging is in place to record what software each system is running, and
what process is in place to audit those logs?
Internal Applications
Internal applications can be almost as much of a risk to security as external
applications. is is due, in part, to the still prevalent misconception that inter-
nal applications have no or little need to be secure as they are in use only within
the company.
Unfortunately, this is not at all the case. ere are numerous cases of internal
abuse of systems and data when security is not adequate for the potential risks.
In the case of very high-risk applications or data with which your project will
directly interact or coexist, you may want to do some further investigation. Some
simple research may give you information on how security was addressed when the
112 ◾ Official (ISC)
2
® Guide to the ISSMP® CBK®
© 2011 by Taylor & Francis Group, LLC
internal application in question was written or updated and, if you are lucky, you
will be able to review that application’s risk analysis or security plan and have a clear
idea of the security landscape.
Some companies mandate the use of Secure Coding Principles for any internal
application development. Secure Coding Principles can greatly increase the security of
new code as it is written and reduce the overall security risk of internal applications.
Some of the important questions to ask about internal applications coexisting
with the project are as follows:
◾ What policies are in place to govern the access to and installation of internal
applications, and how are those policies enforced?
◾ What policies are in place to govern security during internal application
development, and how are those policies enforced?
◾ Is a mandate in place for Secure Coding Principles, and how is that man-
date enforced?
◾ What logging is in place to record what internal applications are installed or
running on user systems, and what process is in place to audit those logs?
Project under Development
Now you move from the environment within which your project will exist and with
which it will interact and focus on the actual project for which you are managing
security. Some of the security focus now moves from purely being security of the
nished product to security of the development process as it occurs.
Secure Coding Principles
e Secure Coding Principles are a collection of basic concepts that, if learned and
implemented by all members of the development team but especially the develop-
ers, can lead to more secure software from the point of initial development. is is
a great start to an application being secure by design, but not all development teams
are willing to sign up to follow these principles.
If you can sell the development team on making the following Secure Coding
Principles a requirement of the software development process, you have an immedi-
ate leg up on making the project secure:
◾ Security by design: Integrating security design principles into the product
and assessing the product’s security throughout the development process.
◾ Least privilege: is is the principle of not giving a user any more access or
permissions than the user actually needs to perform a necessary task.
◾ Exclusive rights: is is the need to lock les or resources while in use to pre-
vent race conditions in which multiple users issue conicting or overwriting
instructions and the outcome can be uncertain.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.