Security-Assessment-White-Paper

Security as a
Practice
Author: Vivek Sharma
9/10/2015
http://www.nalashaa.com/
nalashaa solutions llc.
555, US Highway One South, Ste 170, Iselin, NJ 08830

Security is a subject which is most talked
about in the IT industry. However, the
industry continues to grapple with
threats from the environment external
to their applications. Such malicious
intents result in what we know as
cybercrime, hacktivism, and cyber
warfare & espionage.
In 2014, the breach of Sony Pictures
Entertainment is was the biggest data
breach of the year and among the
most devastating to any corporation
ever.
Attackers broke in and took whatever
they wanted, exfiltrating gigabytes and
gigabytes of documents, emails and
even entire movies, apparently at will
for months and months. Data
compromised – Seemingly everything
stored in the network.
Statistically, Retail and Financial/
Insurance sectors were the worst hit by
security breaches in 2014. In order to
secure their applications, companies
spend millions of dollars on external
consultants, tools, and other devices, but
the visible advantage is minimal in
comparison to the budget spent on
security, and they cannot guarantee that
their systems are 100% secure.
As per Gartner,
Worldwide spending on information
security will reach $71.1 billion in
2014, an increase of 7.9 percent over
2013, with the data loss prevention
segment recording the fastest growth
at 18.9 percent, according to the latest
forecast from Gartner, Inc. Total
information security spending will
grow a further 8.2 percent in 2015 to
reach $76.9 billion.
From these excerpts, we can imagine the
magnitude of the effort, money and
devastation linked to these anticipated
security breaches.
One of the reasons for application
vulnerabilities is sadly the misalignment
of motivations of the development
organization and that of internal IT team
that keeps them up and running. It has
been observed; organizations perceive
security concern distinctively from the
normal project execution. They address
the security aspect once the application is
ready. By this time, there is a mounting
pressure of releasing the application to
different environments, having the
security issues partially implemented or
sometimes ignored, and leaving scope
for hackers to rub shoulder with the
application.
Figure 1: Above diagrams shows Cyber Attack Distribution
Security as a Practice

In this whitepaper, I will discuss about
the practice of addressing the security
concerns as part of the SDLC process.
SLDC Practice – A view through the
security lens
Broadly speaking¸ a typical project has
several stakeholders (apart from the
client), such as Business Analysts,
Architects, Developers/DBAs, Testers,
Release Administrators, and managers
(Project and Release Managers). Each of
them contributes significantly at different
levels. Each of them should understand
the security concerns at their levels.
Most importantly, Organizations too
should have certain security policies to
be compulsorily adhered to.
Business Analysts should think of
security when writing specifications.
Any possible security concerns should be
communicated to all stakeholders
Figure 2: Cyber Attack Techniques
Architects have a crucial role among all
(does not mean others are discounted).
Security should be taken as an Aspect.
Robust security architecture should
integrate loosely with multi-tier
architecture of the application that
oversees the security at all tiers of the
application architecture non-intrusively.
The SDLC should adhere to the
Guidelines of ISO/IEC 27034 for
application security. ISO/IEC 27034
offers guidance on information security
to those specifying, designing and
programming or procuring,
implementing and using application
systems. The security architecture should
compulsorily address concerns on
Authentication, Authorization, Audit,
Assurance, Availability, Asset
Protection, Administration, and Risk
Management. Typical artifacts for
security architecture includes Business
Rules pertaining to data and information
assets usage, ownership and custody,
published Security Policy of the
organization, risk analysis, and data
classification policy documentation.
CVE (Common Vulnerabilities and
Exposure) portal should be referred
before recommending technologies.
Figure 3: Integration of security architecture in an application’s
architecture.

The prerequisite to have a security
centric Development Environment is to
educate Developers about the concerns
of software security. Security should not
be project based, but it should be
intrinsic part of every project. Managers
should step in to ensure this in various
teams. They should be involved along
with the guidelines and policies to create
a secure environment for deliveries.
Typically, Developers should refer to the
secure frameworks/projects such as
ESAPI, Apache Shiro and HDIV for
implementing any enterprise
Implementation to Access Control,
jGaurd, OACC can be used. Encryption
Implementations can use Keyczar,
Bouncycastle, Windows DPAPI and so
on so forth (there are several other
libraries that are not listed here.)
The estimates for developing a feature
should contain estimates for addressing
the vulnerabilities. Apart from these,
developers should follow certain best
practices, such as the validation of each
layer should be done at its level, and not
on upper layers. For example, In a multi-
tier application, server side and database
security should be handled at middle tier
and database tier respectively and not on
presentation tier. Inputs should be
encoded. Output should be decoded
before rendering to frontend. All form
inputs and URLs in query string should
be whitelisted.
Mobile application developers should
understand the threat model for the
system. All data crossing the boundary
should be validated, and should not be
used to make critical security decisions.
All decisions about the data stored on the
device should be made carefully. iOS
and Android developer should adhere to
the recommendations in "Apple's Secure
Coding Guide" and "Android security
discussions" by application. To limit the
Google Group, and guide by iSec
Partners for "Developing Secure Mobile
Applications for Android" respectively.
Development environment should be
integrated with plugins and tools to
ensure vulnerability testing and fixing
during development. Firefox exploit-me
add-ons can be used for unit testing.
However, a reliable software penetration
tool such as NESSUS should be used to
detect more vulnerability during
integration testing. These should be fixed
on priority without compromise.
A good code review tool such as
FindBugs, Owasp SWAAT, Google
CodeSearchDiggity for Java, FxCop for
.net and RATS for php, C/C++ and
python etc. to checks for any vulnerable
code should be used instead of manual
review.

Tool such as Owasp Zap should also be
integrated in system test (QA)
environment to test vulnerabilities
aggressively. Tester should include test
cases where they can exploit the
syntactical limitations of programming
language, and access control limitations
of database, cloud (if a cloud hosting is
part of application) and file systems.
This practice, in fact will bolster
integrity of sprint teams to release teams
are an integral part of creating secure
development environment.
Figure 4: Integration of security add-ons, tools and libraries in DEV
and QA environments.
They should manage several code
branches in a way to create the best
combination for the project, including
hot fixes. The release infrastructure
should be created early and should be
stable. Process should be strictly
followed, and must be automated as
much as possible. The release
environment should be isolated from
development teams.
The application support team should put
in place a robust incident management,
and any fatal alert should be analyzed
and fixed on priority. If logs are passed
to development team for analysis, all
data in the log should be encrypted or
masked to produce quality Software.
Social Engineering
This is the most neglected aspect of
software security. The organization as a
whole should review the security
guidelines and policies regularly. It has
to ensure that all its resources including
people practice secure habits. Suitable
training sessions should be conducted,
and it is ensured that employees
understand and value it. Password
protection, Remote Hardware/Software
monitoring, Auditing etc. should be done
to check any unauthorized usage of its
resources.
Figure 5: The social aspect of Security.

Return on Investment
ROI for software security is seen as
reduction in risk. It is not justified to
generalize the ROI on software security,
because this ROI depends on executed
on a software component/application for
the company. Typically, we need to
measure something to calculate the
Return on Investment. We measure the
Extent of Loss to calculate the ROI on
security implementation.
Broadly classified, following Losses can
be used to calculate ROI.
• Productivity Loss of Employees due
to security breach, and the duration of
the same.
• Loss of Revenue from Outages.
• Loss of Data, if temporary the cost to
recover it, if permanent, how much
revenue is written off.
• Compromise/Modification of data,
the extent to which it is done, and the
cost of recovering and protecting it.
• Loss of Reputation, caused due to
disclosure of all the breaches as
enforced by govt. regulation the
criticality of the business operation.
Conclusion
As said that early investment is always
better.
Ensuring healthy security practices
reduces the risk of application getting
hacked, and helps protect data and other
resources significantly. It creates a
distinguished identity for the
organization among its peers in Industry,
which in turn increases its credibility and
strengthens trust among its client. Not to
forget the budget part of the project,
following a consistent security
development practice reduces the
spending on software application
security considerably.
References
Figure 1, 2:
http://www.hackmageddon.com/2015/04/
13/march-2015-cyber-attacks-statistics/

Security-Assessment-White-Paper

Recomendados

Recomendados

Más contenido relacionado

Destacado

Destacado (20)

Security-Assessment-White-Paper