118 ◾ Official (ISC)
2
® Guide to the ISSMP® CBK®
© 2011 by Taylor & Francis Group, LLC
Watch for Common Application Programming Interface Issues—Some issues
are more common in application programming interfaces (APIs) than in other types
of applications or are specic to APIs. Some of these are as follows:
◾ Reliance on the implementation details of a particular programming lan-
guage to act as implicit security.
◾ Reliance on perimeter security in place of defense-in-depth. Once the perim-
eter is breached, everything is wide open.
◾ API abilities open to anyone. is can lead to misuse of API abilities by other
software or attackers.
Choose the Programming Language with Care—Although secure code can
be written in any programming language, some programming languages are more
prone to specic issues than others by virtue of the language and its programming
principles. ere are a number of languages to choose from, and the decision of
language may be a done deal based on the preferences and needs of the enterprise,
but there are some common language issues to be aware of.
Scripting languages, in general, are not designed to be secure. Some scripting
languages, like JavaScript, have security models, but these models are designed
more to protect the clients from malicious Web sites and not to protect the data or
servers. Additionally, scripting languages are known to have a considerable number
of security defects. If you intend to use a scripting language for all or part of your
project, researching aws in that particular language will give you a good idea of
what to look for and what to add to the risk analysis.
Many programming languages like C and C++ give developers a huge amount
of control over things like pointers, memory management, etc. e downside
of this control is the increased risk of security defects in the code caused by
relatively simple errors. If one of these languages is chosen, this risk should be
mitigated by requiring automated or focused security code reviews to ush out
these coding issues.
Some newer programming languages like .NET take that ne control of
memory and pointers away from the developers. Although this gives less ne con-
trol, it helps to mitigate the common security aws in code by taking care of vari-
able, pointer, and memory management as well as buer sizing, etc. If one of these
languages is chosen for the project, there is still a risk of poor security practices in
coding and mitigation that should be called out.
Web 2.0 Considerations—Web 2.0 is the term for the brave new world of Web
design and technology rather than a language or technology in and of itself.
Web 2.0 tends to focus on the movement of Web-delivered content. Lightweight
applications are common and are supported by content syndication so users can
run applications entirely within a Web browser.
Enterprise-Wide Systems Development Security ◾ 119
© 2011 by Taylor & Francis Group, LLC
If your project is being designed as a Web 2.0 project, the technologies being
used should be researched and the risk of using those languages mitigated with a
security code review.
No particular language or technology is required for something to be consid-
ered Web 2.0, but there is a key set of security principles that should be used.
◾ Encryption is a must because data is, by design, being transmitted over the
intranet or Internet.
◾ Strong validation must be used to counteract the fact that interactive Web
applications are often vulnerable to input attacks.
◾ Server congurations must be secured and the server hardened.
◾ Data must be secured both in transmission and in storage or backup.
◾ All systems must still have up-to-date security software and the most current
patches and updates applied to remain as secure as possible.
Documentation—Documentation of the project and the project security can be both
a security issue and a benet, depending on who has access to the documentation.
Only those people with a requirement to have access to the system’s documenta-
tion should have that access. is means that some people will need access to user
guides or instructions but will not need access to development documentation or
security documentation.
In general, security and development documentation should be secured in a
location with limited access and never released externally to the company.
Separating the documentation by security level or area can mitigate the risk of
this documentation being released, but this must be weighed against the inconve-
nience to people who require access having to look in multiple places.
Virtualization Risks
Another popular movement is toward virtualization, especially toward virtual
machines. Virtualization can allow one computer to do the job of multiple comput-
ers by creating “virtual” system resources like RAM, disk space, etc., to run what
amounts to another system on the same hardware. Both virtual servers and virtual
desktops are becoming more and more popular.
Virtualization is still rife with undiscovered and unrealized security threats, so
the list below is not at all complete. If your project is planning to use virtualiza-
tion, you should do more in-depth research into the current state of virtualization
security, especially as it applies to the particular virtualization scheme the project
plans to use.
Some of the security risks already raised for virtualization are as follows:
120 ◾ Official (ISC)
2
® Guide to the ISSMP® CBK®
© 2011 by Taylor & Francis Group, LLC
◾ Each virtual machine must still be treated as if it were a separate machine and
its operating system and software kept updated and patched.
◾ Each virtual machine must still have security software installed and kept up
to date.
◾ e virtualization software must be kept up to date and patched.
◾ A new vector for attacks now exists between host and guest machines or even
between dierent guest machines on the same host that may not adequately
be addressed by current security software.
◾ Because virtual machines use the same hardware (network card, etc.) to inter-
act with the network and resources, it may be dicult to audit logs and cor-
rectly identify trac sources.
Quality Control
e project’s quality control eorts can also be a source of security issues that go
largely unrecognized and unmitigated. Because quality control is tightly tied to
the project, it often has high-level access to the project and its resources as well as
scripts, tools, hooks, or other resources designed to bypass the system’s security to
make testing easier.
Some of these risks can be mitigated without a huge amount of eort, but
should be added to the risk analysis and project plan.
◾ Test data should not include real or live data if the data is sensitive. is is
a common issue in projects that use databases because there’s a desire to use
real data to test as close to live content as possible. is creates an unnecessary
security risk because now a copy of the live database is housed in a location
whose security is unknown and the access rights are also unknown. It’s a
relatively trivial task to create true dummy data to test with and mitigate this
risk completely.
◾ Test hooks and code are included in the project code. is creates a risk
because this test code is often designed to give access to features and func-
tions not designed for direct access in order to test it, but the test code itself is
never tested. Shipping this code creates security risks that can be discovered
and used and it might contain its own set of security defects that can com-
promise the project. Auditing to ensure that all test code is removed from the
nal version before it is released can mitigate this.
◾ Test users often have high-level access to the project while it’s being tested
and sometimes this access is not revoked on release of the project, which
creates security risks that the user can exploit later. Auditing to ensure that
all test users and permissions are stripped before the project is shipped can
mitigate this.
Enterprise-Wide Systems Development Security ◾ 121
© 2011 by Taylor & Francis Group, LLC
Maintenance Plan
e project’s own maintenance plan may not be determined at the time the project
is rst designed, but there are a few things that impact security that should be kept
in mind and included in the risk analysis if applicable, even as a single entry with-
out current mitigations.
Patches—ese are patches for the project itself, if needed. Some of the important
questions to ask about patch control are as follows:
◾ How will patches for the project be handled to avoid the installation of
bogus patches?
◾ How will required patch installation be enforced?
Code Review—is involves the review of any code changes to the project after
its release. Code reviews are typically required during the initial project design and
development, but when the project goes into its maintenance phase it’s common
for that diligence to relax. is can create security risks when patches are released.
Some of the important questions to ask about code reviews for the project’s main-
tenance phase are as follows:
◾ What code reviews must take place on patches or maintenance for this proj-
ect, and who has to perform those code reviews?
◾ What records must be kept and where on the result of code reviews and any
changes required by the code review?
Threat Modeling and Risk Analysis—When updates or changes are made to the
project, the previously completed threat models and risk analysis become outdated.
In order to keep on top of the project’s security risks and mitigations, the threat
model and risk analysis must be updated. Some of the important questions to ask
about threat modeling and risk analysis for the project’s updates are as follows:
◾ Is there a policy in place to ensure that the threat model and risk analysis are
updated and mitigations are made before updates or patches are nalized and
released? How is that policy enforced?
◾ Is there a policy on where to keep copies of updated security documents for
future reference?
Service-Oriented Architecture Security
Service-Oriented Architectures (SOAs) are those that use Web-based interoperable
services and largely emphasize code reuse, and they are grouped around business
122 ◾ Official (ISC)
2
® Guide to the ISSMP® CBK®
© 2011 by Taylor & Francis Group, LLC
processes. Because of the fact that this is a relatively new architecture and due to
some of the fundamental concepts of its design, it can be a challenge to adequately
secure.
Build to the Strictest Security Bar
SOA applications have an advantage in being much smaller because the applica-
tions are typically made up of calls to dierent blocks of reusable code via program-
ming interfaces. Services are designed to be as general as possible to maximize the
code reuse.
is emphasis on generality is at odds with the security practices of locking
functionality down to only what is required. is is made worse by the fact these
services do not care who they are talking to, unlike traditional security where you
need to know exactly who the user is and what the user’s permissions are.
e result is that if your project needs to use SOA and is handling sensitive
data or applications, then the entire SOA and its components and services and the
underlying infrastructure have to adopt the security practices of the most sensi-
tive data or application.
Implement a Formal Change Process
SOAs are designed so new services can be added and advertise themselves in a
catalog or central repository so applications can make use of them. Unlike tradi-
tional projects where code changes and additions follow a formal review process
and are implemented by specic people or teams, SOAs are designed to not adhere
to any of these. is can lead to rogue or insecure services sneaking in and a loss
of integrity.
If your project is going to handle sensitive data or applications, then a formal
process needs to be implemented and enforced for changes to existing services and
additions of new services.
Enforce Authentication
Because most SOAs do not care whom they talk to, authentication often defaults to
anonymous or none needed, but that violates the security concepts of knowing to
whom you are talking and what they can do.
In order to implement some sort of security, the project can take one of two
basic steps. e rst is to move services and a supporting architecture into a sepa-
rate space where the services and infrastructure can all trust each other and only
each other. ese underlying services and infrastructure pieces must also all meet
the same basic security level.
e other possibility is to adopt a pattern of mutual distrust. is means
authorization must be made and the authorization state maintained and each
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.