Enterprise-Wide Systems Development Security ◾ 103
© 2011 by Taylor & Francis Group, LLC
◾ What applications require access to the database and data to perform their
tasks, and what level of access do they require?
◾ What data is being stored in this database, and what is the sensitivity of
that data?
◾ What data is being stored in other databases sharing the same database server,
and what is the sensitivity of that data?
◾ How is the connection information or access information stored for any
applications or systems that access this database?
◾ How will the project access this database, and how will the connection strings
and passwords be stored?
◾ What logging or monitoring is in place to track access or attempted access of
this database, and what process is in place to audit these logs?
Encryption
Encryption is a valuable security tool to help protect data in case it is exposed or
revealed, because if the data is encrypted, anyone trying to exploit or use it has to
have the encryption key as well as access to the data itself.
ere are multiple levels and types of encryption available, and they will have
varying costs to implement and use, both in time to implement and performance
costs if implemented.
Encryption may already be in place or mandated by the company, but it’s vital
that encryption schemes be agreed upon by every project or system using a particu-
lar database.
Data Encryption—Data encryption is most often used for databases whose data
is considered high risk. Encrypting an entire database can be expensive in terms of
performance, but it may be an acceptable cost of mitigation if the data is of signi-
cant enough value that it’s deemed worthwhile.
Database encryption can also be useful when there is concern that backups
or copies of the database may be at risk and that risk needs to be mitigated. If the
database backup or copy is encrypted, anyone obtaining that backup or copy would
have to have the encryption key to make use of the data.
Some of the important questions to ask about data encryption for each database
the project will use are as follows:
◾ What data will be stored in the database, and what are the potential ramica-
tions of it being exposed?
◾ Is the database already encrypted, and is that level of encryption reasonable
and sucient to the contents of the database?
◾ Are there any other systems that must interact with the database, and do they
currently support any data encryption policy?
104 ◾ Official (ISC)
2
® Guide to the ISSMP® CBK®
© 2011 by Taylor & Francis Group, LLC
◾ Is there a company policy or standard for data encryption that would apply to
the database, and how is it enforced?
◾ Is there a regulatory or legal policy or standard for data encryption that would
apply to the database, and how is it enforced?
Connection and Traffic Encryption—Encryption of the data as it is carried on
the network is another aspect of data security. Network trac can be snied and the
packets intercepted, but having the data encrypted means the attacker must have
the key to make sense of the captured data.
is can be especially important if the data trac takes place over the Internet
as trac interception can be very easy.
Some of the important questions to ask about connection and trac encryption
of database trac for each database the project will use are as follows:
◾ What data will be transmitted to and from the database, and what are the
potential ramications if it is exposed?
◾ Is trac from the database already encrypted, and what encryption standard
is being used?
◾ Are there any other systems that must transmit data to or receive data from
the database, and do they currently support any encryption policy?
◾ Is there a company policy or standard for encryption of data that would apply
to the data transmission, and how is it enforced?
◾ Is there a regulatory or legal policy or standard for data encryption that would
apply to the data transmission, and how is it enforced?
Maintenance Plan
In order for the project’s databases and database servers to remain secure and
functioning properly, regular maintenance is a must. A security-conscious eye
toward typical maintenance allows planning for these events in advance and pre-
vents the use of insecure and seat-of-the-pants maintenance eorts or no mainte-
nance at all.
Maintenance of the database server and databases can include some security
risks, depending on who is maintaining the server and database and what functions
they are performing.
Auditing—Auditing must be conducted 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, prefer-
ably in a secure location that is not on the server itself. Someone must be respon-
sible for reviewing these logs, and there must be a policy in place for what to do if
security-related issues are found.
Enterprise-Wide Systems Development Security ◾ 105
© 2011 by Taylor & Francis Group, LLC
Some of the important questions to ask about the auditing of each database and
database server the project will use are as follows:
◾ What logging is in place to record server-level events like access attempts,
etc., and what process is in place to audit these logs?
◾ What logging is in place to record database-level events like unauthorized
access attempts, invalid queries, etc., and what process is in place to audit
these logs?
◾ What logging is in place to record network events that may be aimed at the
database or server, 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 database and server for security-related issues, and who is in
charge of doing it?
◾ Is there a policy in place to ensure that monitoring and log auditing are being
done by a party or parties who are not likely to be the source of security issues
that would appear in those logs, and how is it enforced?
◾ What actions must take place or who must be notied if a security-related
event is detected during an audit?
Patches and Updates—Regular patching of the database software and the
database server provides better 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 of the important questions to ask about patches and updates to each data-
base and server the project will use are as follows:
◾ Who is or will be responsible for applying patches and updates to the server
and database?
◾ What are the ramications of the server or database 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 or database, and how are they enforced?
◾ Is there auditing or enforcement of update and patch policies that would be
applied to the server or database?
◾ Is there a requirement to failover to a redundant database or server during a
patch or update to ensure minimal downtime, and how is this enforced?
Backups—Database backups are a familiar routine in order to provide a copy of the
data in case of a failure. But there are security considerations around the backups,
106 ◾ Official (ISC)
2
® Guide to the ISSMP® CBK®
© 2011 by Taylor & Francis Group, LLC
including storage and access questions. Some of the important questions to ask
about database backups for each database the product will use are as follows:
◾ Who is responsible for creating database backups of the database?
◾ Are there company policies or guidelines on making, storing, or the retention of
database backups that would aect the database, and how are these enforced?
◾ Who can make a backup of the database on demand?
◾ What logging is in place for database backup requests, and what is the process
for auditing these logs?
◾ Where are the database backups stored, and who has access to that storage?
◾ What logging is in place for accessing the database backups, and what audit-
ing is in place to look at these logs?
Web Servers
More and more enterprises are moving to Web-based services for important func-
tions or operations, and this brings Web servers even more into the domain of a
security manager who deals with the security of enterprise systems.
is move to Web services and servers has great advantages for some functions,
but it is all too often a victim of more lax than needed security when that security
is relaxed because the software is only intended to be used in house.
Yet at the same time, more and more enterprises are enabling employees to work
from home over a Virtual Private Network (VPN) or to use remote access solutions
to access workplace services from home via the Internet.
Server Restriction
Web servers should be restricted in ways not required by servers or systems in other
roles in order to increase their security. ese restrictions are in addition to, rather
than in place of, the normal system security measures and are intended to mitigate
some of the specic vulnerabilities of Web servers.
Because of their accessibility, the number of vulnerabilities, and the fact they
often serve as front ends to databases with valuable content, Web servers are popu-
lar targets for internal and external security threats.
Location—e physical and network location of the Web server can mitigate one
of the major risks of it being a Web server—that compromise of the one Web server
can put other machines, clients of the Web server, or even the network at risk.
Because Web servers are such targets, it’s good practice to not allow a server to
act in the role of both a Web server and another type of server, especially a domain
controller or backup domain controller. If a Web server that was also acting as a
domain controller is compromised, there is a potential that the entire domain will
be compromised.
Enterprise-Wide Systems Development Security ◾ 107
© 2011 by Taylor & Francis Group, LLC
Best practices for security and Web servers require that the Web server be iso-
lated in a demilitarized zone (DMZ) where it is separated from the rest of the net-
work, including any databases or resources it may use, by a rewall.
Some of the important questions to ask about the physical and network location
of each Web server the project will use are as follows:
◾ Is the Web server isolated in a demilitarized zone (DMZ) and, if so, what else
is located in this DMZ?
◾ Is there a rewall between this DMZ and the rest of the network?
◾ Where is the server physically located, and who requires physical access to it
in order to perform their job functions?
◾ What logging is in place to record access and access attempts to the physical
server, and what process is there to audit these logs?
◾ What logging is in place to monitor the server’s network access and access
attempts, and what process is in place to audit these logs?
◾ Is the Web server also acting as another type of server or resource?
◾ If the Web server uses a database as a back end, are the Web server and data-
base separated to ensure better security?
◾ What logging is in place to record access and access attempts that touch the
rewall, and what process is in place to audit those logs?
Port Restrictions—Because a Web server is intended for a particular use, the
vast array of available ports and port trac should be limited to use or acknowl-
edge only the ports actually needed to perform as a Web server for the project.
Leaving ports open that are not required exposes the Web server to security risks
from port attacks and potential software vulnerabilities in software listening on
various ports.
Ports should follow a similar white-list approach to that of access control. All
ports should be shut down and then only those required for the Web server to
perform its tasks for the project should be opened as exceptions. e two standard
ports to leave open are port 80 (http) and port 443 (https).
Some of the important questions to ask regarding Web server port restrictions
for each Web server used by the project are as follows:
◾ Are all ports other than 80 and 443 shut down?
◾ Does the project use any other ports, and why?
◾ Does other software running on this machine require ports other than 80
and 443 to be open, and why?
◾ What logging is in place to record changes to port activations and deactiva-
tions, and what process is in place to audit these logs?
◾ What logging is in place to record port access attempts, successful or unsuc-
cessful, and what process is in place to audit these logs?
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.