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

http://www.nalashaa.com/

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



http://www.gartner.com/newsroom/id/2828722


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

Documents