Enterprise-Wide Systems Development Security ◾ 113
© 2011 by Taylor & Francis Group, LLC
◾ Secure memory management: is is the principle of securing memory man-
agement by maximizing the use of careful bounds checking, minimizing the
use of pointers, and cleaning up pointers as soon as they are no longer needed.
◾ Keep it simple: is is the principle of creating the simplest solution to a
problem to minimize security problems in that code.
◾ Protect the data: is is the principle of never hard-coding passwords and
always encrypting any passwords or sensitive data.
◾ Trust nothing: is is the principle that requires everything to be tested
before being used. is includes checking that the input is good and, if not,
that it fails gracefully.
Some of the important questions to ask about Secure Coding Principles for
your project are as follows:
◾ Have the Secure Coding Principles been made into a requirement for this
project?
◾ How often will the project be reviewed with an eye toward the Secure
Coding Principles?
Secure Development
Beyond the Secure Coding Principles, there are additional aspects to project secu-
rity that must be considered and dened, preferably before the project development
really gets under way.
Security-related requirements need to become an integral part of the project
requirements, and that necessitates them being dened and agreed upon early in
the process.
Define Security Quality Bar—e basis for a lot of decisions relating to security
during the development of the project will be what the agreed upon security qual-
ity bar is.
e security quality bar is used in conjunction with the risk analysis to dene
what security issues must be addressed in order to ship the project. is is often
addressed as a requirement that all severity 0 and 1 risks will be mitigated or a
similar statement.
e purpose of this is to set a minimum quality bar, specically for security,
that will help indicate when the project can be released. It also prevents spending
a huge amount of time on trying to mitigate all security risks at the cost of the
project taking far longer than usual. is security quality bar is documented as
part of the risk analysis and security plan and is referenced by other project devel-
opment documents.
Some of the important questions to ask about the security quality bar for your
project are as follows:
114 ◾ Official (ISC)
2
® Guide to the ISSMP® CBK®
© 2011 by Taylor & Francis Group, LLC
◾ If the risk analysis is put in order of overall severity according to the project
and its environment, what is the maximum acceptable risk for the project?
◾ If a mitigation is made, what is the new severity of that risk, and is it below
the acceptable risk for the project?
Require Security Reviews—In some cases security reviews will be a known
requirement due to legal or regulatory requirements. In this case, you need to gather
the development team and make its members aware of the requirements the project
must meet and how it will be tested.
If there is no externally mandated security review, is there a company policy
in place that requires security reviews and sets the requirements the project must
meet? If there is, then the development team must be made aware of them.
If there are no mandates, then a decision must be made based on multiple
factors like budget, internal resources and knowledge, and the security risks of
the project about whether to conduct a formal security review of the project as a
requirement to it being released.
Some of the important questions to ask about security reviews for your project
are as follows:
◾ Is there a legal or regulatory requirement for a security review and, if so, what
are the requirements that have to be met, and who has to conduct the review?
◾ Is there a company policy or requirement for a security review and, if so, what
are the requirements that have to be met, and who has to conduct the review?
◾ If there is no external requirement for a security review, is the project sensitive
enough to warrant a formal security review as a requirement for release? If so,
what should the criteria be, and who should conduct the review?
◾ How many security reviews should be held?
Protect Source Code—An aspect of secure development that is often overlooked
is the need to protect the source code of the project, both as it is being developed and
afterward. Leaks or releases of source code can result in a huge security breach, so
access to the source code should be limited to only those people who actually require
that access to perform their job functions, and all other access should be denied.
Protect Defect Details—Another aspect to security during development is the
need to protect the defect database and details contained in it, especially those
relating to security. Most defect reports contain a sample of how to cause the defect
to manifest itself, and exposure of that database can lead to exploitation of those
defects later.
e defect database should be locked down, and only those people who require
access to the defect database to perform their job functions should be given access
to it. If there is a need to have other people le defect reports, it may be a worth-
while risk mitigation to set up a method just for that purpose.
Enterprise-Wide Systems Development Security ◾ 115
© 2011 by Taylor & Francis Group, LLC
Watch for Common Issues Overall—Even though you are not in charge of the
actual coding during development, it is a good idea to be generally aware of com-
mon security aws to be able to watch for situations in which they commonly
occur and ask the right questions about their mitigation.
ese issues are broken down into broad areas for easier consumption, but this
is not an expansive or exhaustive list, and it is certainly not complete. For more
details and ideas, you should research the known or common security issues that
may have come to light by the time you are working on the project.
e key to identifying security issues is to take the core concept of the issue and
extrapolate it to cover your project. is is because too close a focus on an isolated
issue can lead to missing a similar one because it’s not the same language or doesn’t
work exactly the same way.
Input and Information Validation Issues—Many security issues are related to input
and stored information and how that information is handled. ese issues include
the following:
◾ Not validating all input, all input formats, and all input sources. Nothing
should be trusted or taken for granted.
◾ No graceful exit if input is not valid. Invalid or unexpected input should not
cause the security to fail.
◾ Information is stored in the registry or system path and, once stored, that
information is trusted without further validation. Registries and paths can
be hacked or modied.
◾ Hidden les and directories are being used for saving and retrieving trusted
content without further validation. Security by obscurity is no security at all.
Installation Issues—ese are issues that occur when the nished project or one of
its components is installed and include the following:
◾ Risky features are enabled in a default installation. Default installations should
require independent action to turn on or activate features deemed as risky.
◾ High permissions are required to install the project or component, but are
not required to execute it. is can lead to someone with lesser permissions
running an application that he or she should not be able to.
◾ Installation locations are hard-coded. is leads to both always knowing
where the application and its data exist and an inability to customize instal-
lation for each system.
Authentication Issues—ese are issues that occur during execution of the project or
its components and include the following:
116 ◾ Official (ISC)
2
® Guide to the ISSMP® CBK®
© 2011 by Taylor & Francis Group, LLC
◾ User authentication occurs only once or only at certain points. Once
an authentication area is bypassed, the system is open with assumed
authentication.
◾ Access control rules are not enforced consistently. If an Access Control List
(ACL) is in place, it must be respected and enforced.
Cryptographic Issues—ese are issues related to the use of cryptography in the
project or one of its components and include the following:
◾ Custom cryptography is being used instead of tested and veried standard-
ized cryptography.
◾ Homegrown cryptography is notoriously insecure.
Information Disclosure Issues—ese are issues related to information the project or
one of its components displays back to the user or les and include the following:
◾ Errors are displayed in a manner that discloses project infrastructure details.
Users should be given only the information they absolutely need.
◾ Temporary les are created and data is stored in those les then later trusted
with no further validation. Temporary les are easy to compromise.
◾ Crash les and logs contain sensitive information about the project. Again,
no information should be disclosed that is not absolutely needed.
◾ Cached information is trusted without further validation. Caches can be
tampered with and compromised.
◾ Information is disclosed that is not actually needed by the user.
Execution Issues—ese are issues related to the actual execution and running of the
project or its components and include the following:
◾ e project runs at an unnecessarily high privilege. If the project is compro-
mised, that high privilege can be hijacked and used.
◾ e project defaults to a less secure version in case of an error or execution
problem. Sometimes done for compatibility, it instead leads to risks if an error
can be caused.
◾ Default accounts are used to run the processes. e default accounts tend to
be easy to guess and misuse.
◾ Session cookies are weak or easily reused. is is an invitation to session
replay or cookie tampering.
◾ Sessions are persistent. is can be a sign of a session vulnerability.
Output Issues—ese are issues related to the project output and how it is han-
dled. ese issues include output can be intercepted before reaching its desired
destination.
Enterprise-Wide Systems Development Security ◾ 117
© 2011 by Taylor & Francis Group, LLC
Watch for Common Web Server Issues—Some issues are more common in
Web servers than in other types of applications or are specic to Web servers. Some
of these are as follows:
◾ Server processes run at a high privilege. is means that if the process can be
hijacked then other code can be run at the same high privilege.
◾ Default accounts used to run server processes. ese accounts are easy to
guess and compromise.
◾ Trust granted based on a custom packet format. Packet formats are easy to
sni and replicate.
◾ Transmission of unencrypted data. Any data sent in plain text is sniable.
◾ Hidden form elds not validated. Another case of obscurity is not security.
All elds must be validated.
◾ Trust granted based on transmission method. Any transmission method can
be used for malicious data.
◾ No validation to authorize clients. is can lead to the use of rogue or unau-
thorized clients.
◾ Trust granted to data based on source. Legitimate clients can be subject to
data hijacking.
◾ Lack of nonrepudiation/antirepudiation validation. Legitimate transactions
can be reversed or denied.
◾ Clients not validating the server. is can lead to legitimate trac being sent
to a rogue server.
◾ Clients verify only server, not data. is is another risk for session hijacking.
◾ Perimeter safeguards trusted for all security. If those safeguards are defeated,
the entire system is open.
◾ Encryption keys stored in source code. Source code can be disassembled or
copied and keys found.
Watch for Common Database Issues—Some issues are more common in data-
base servers and databases than in other types of applications or are specic to
databases and database servers. Some of these are as follows:
◾ Database access not locked down by IP. Anyone can talk to the database
server and the security risk is increased.
◾ Actions taken without validation. is can lead to SQL injection or other
vulnerabilities.
◾ Actions and permission granted to default users. ese accounts are easy to
guess and misuse.
◾ No table access control. is allows actions that are not part of the database
design to be taken on tables where that should not be allowed at all.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.