Data Leakage & Application Programming Risk MitigationRon McFarlandBlockedUnblockFollowFollowingMar 28Data Leakage & Application Programming Risk Mitigation: A starter for the Java Programming Languageby Ron McFarland, Ph.
D.
Risk mitigation continues to evolve in the cybersecurity space.
A key observation that speaks to the shifting sands of risk mitigation is noted in the Hewlett Packard Enterprise Cyber Risk Report of 2016.
HP researchers indicated that attackers have shifted their focus from servers and operating systems directly to applications (Enterprise, 2016).
For application development teams, this shift places even greater emphasis on the development of secure code and the protection of code once deployed.
eSecurity (2019) supports the developing risk-trend for application development as the attack vector is morphing because of faster internet connectivity and the migration to the cloud for a variety of application platforms.
One of the primary concerns with developing secure code is to protect against data leakage which may be the result of a poorly written or supported (updated) applications.
Leaking Data from application code is, unfortunately, all too common in today’s world.
Each week, we hear of another organization that has fallen victim to a significant data breach, exposing sensitive and protected information.
This article focuses on an aspect of application risk — that of data leakage.
In terms of the broad scope of the data leakage risk, this discussion can be considered only as a primer.
Data leakage has been attributed to many confidential data breaches all too prevalent in today’s information technology world.
Data leakage can result from unauthorized transmissions of data from within the organization to an outside entity.
Further, data leakage can also occur via email, USB devices, media devices, or web interfaces.
In addition, data leakage is often referred to as ‘slow data theft’ that significantly contributes to the loss of essential organization data, including Intellectual Property (IP) and user’s Personally Identifiable Information (PII).
For the client who has been exposed to a hack, the breach can significantly cause financial damage to the organization, risk termination of contract work (especially for defense-related contractors), and will often create a public relations nightmare for the affected company.
Data leakage is a significant concern for application developers coding in a large variety of languages and is a broad-reaching topic that includes error handling and a multitude of other coding practices.
Data leakage is often the result of ineffective programming practices in any language that does not focus on secure coding practices.
Coding for ExceptionsA significant issue in developing secure Java coding is for the programmer to address exceptions.
Unmanaged exceptions can be the doorway for an attacker to exfiltrate data from an information system.
To narrow the doorway for data leakage, coding for exceptions can mitigate some of the data leakage issues.
For the Java developer, guidance is provided Carnegie Mellon’s Software Engineering Institute (SEI) Computer Emergency Response Team (CERT) available on the SEI CERT Oracle Coding Standard for Java (McMangus, 2018) wiki page.
In general, an exception is, from the program’s perspective, an unwanted event.
The exception, such as a file that is not present when the program expects one, should be addressed by the programmer, not only to provide a message that is understandable to the user, but can provide a more secure program.
Exceptions can be managed to effect more secure code.
The Software Engineering Institute at Carnige Mellon University notes that poor exception handling is one major culprits in Java for data leakage (McMangus, 2018).
Exception handling is considered to be one of the most important features in Java.
Exception handling allows the programmer to handle the unexpected or unwanted runtime errors that occur during module execution.
An exception interrupts the normal (the designed) flow of the program and, if exceptions are not sufficiently addressed by the code, an opportunity may exist for the hacker to take advantage of this coding flaw.
At a basic level, the essence of exception handling is to have the module provide a meaningful message to the user as opposed to using a system generated default error message.
Importantly, the code must be examined when the program returns an error for any exposed items such as the inadvertent leakage of file paths, information regarding the state variables of the program, any information about users that may be sensitive including passwords, SSN’s, PII, and other protected information.
To clarify the context of this article, an error is distinct from an exception in the world of Java.
Java uses the Throwable class as a superclass of all errors and exceptions.
Java restricts the objects that are instances of the Throwable class (or one of Throwable’s subclasses) that can be thrown by the JVM (Java Virtual Machine) or which can be thrown by the Java ‘throw’ statement.
In general, an error is a problem with ‘the environment’ that the application runs.
In contrast, exceptions happen at the (running) application level.
There are many examples of what constitutes an exception noted in textbooks and other programmer reference documentation.
For our discussion, if the module attempts to open a non-existent file, or if a particular software port is unavailable, it is best that the programmer code in a particular exception for this typically unexpected event, as a few examples.
In a finite way, handling exceptions can be said to be akin to the ‘control of chaos’ in the ecosystem where an application may execute.
SEI CERT Coding GuidelinesWhile exception handling is significantly more complex than this short article, listed below are a few of the many of the SEI CERT coding guidelines, which provide a flavor for best secure coding practices.
The SEI CERT guidelines, which are frequently updated to support Java development provides very specific remedies for multiple instances that can contribute to data leakage.
Exceptions disrupt the expected control flow of the application, so any exception must be handled appropriately as to not default to the operating system.
For example, the following Java coding rules found on SEI’s wiki provide specific guidance, as noted in the four of many of the SEI-CMU Java coding rules listed on the website:FIO00-J.
Do not operate on files in shared directories: This type of verification seems a bit obvious as shared directories in multiuser systems allow a variety of users with different privileges to use a file system.
Each user in such an environment must be able to determine which files are shared and which are private, and each user must be able to enforce these decisions.
FIO01-J.
Create files with appropriate access permissions: As noted by the CMU-SEI wiki, files on multiuser systems are generally owned by a particular user.
The owner of the file can specify which other users on the system should be allowed to access the contents of these files.
These file systems use a privileges and permissions model to protect file access.
When a file is created, the file access permissions dictate who may access or operate on the file.
When a program creates a file with insufficiently restrictive access permissions, an attacker may read or modify the file before the program can modify the permissions.
Consequently, files must be created with access permissions that prevent unauthorized file access.
FIO52-J.
Do not store unencrypted sensitive information on the client side, or through the use of insecure cryptographic standards such as the Data Encryption Standard (DES) and the Electronic Codebook (ECB) mode of operation, as described in MSC61-J: Do not use insecure or weak cryptographic algorithms (Mohindra & Leung, 2018).
IDS03-J.
Do not log unsanitized user input, inclusion of unsanitized user input in log entries: Ignoring this coding requirement can result in the creation of fake or misleading log messages that obscure an attacker’s true actions.
There are many other Java coding rules on the SEI-CMU Java wiki website that must be incorporated into secure code.
However, the tough part of coding in a large Java development effort is to ensure that each SEI coding guideline is examined and implemented in the associated project code.
Using tools to guide developmentThere are several ways to manage secure coding in a development environment.
Certainly, this is not a comprehensive list.
However, the following three items provide some initial guidance for the developer or technical project manager.
1.
The use of a consistent tool that supports a complete build life cycle: For example, the Apache Maven project is a project management and comprehension tools that support team development and the complete build lifecycle framework for application development.
Maven is a project of Apache and the details are provided on the Maven website (https://maven.
apache.
org/developers/conventions/code.
html).
While the Apache Maven website indicates that by using Maven is “mainly for consistency, readability and maintainability reasons,” an essential part of developing secure coding is consistency.
In a team environment, code walkthroughs are supported by developing code consistently between teams.
Effective and expedient code walk-throughs to examine for errors is supported by a defined and consistent development process.
The development team using Maven can automate the build infrastructure rapidly, as Maven supports a default build lifecycle and a standard directory for the given project Further, the consistency of development can support rapid discovery and remediation of a program/module that has been identified as an issue in an exfiltration situation.
2.
Use of third-party audited libraries: Third-party code/modules/frameworks can assist in the rapid development and thus, rapid deployment of an application project.
The caveat with using a third-party library is to ensure that the code has been audited, verified and updated.
While the most critical vulnerabilities of third-party libraries are disclosed as CVEs (Common Vulnerabilities and Exposures), the key issue is that applications that use the noted CVE-identified third-party libraries/modules often are not updated in a timely manner.
3.
Proactively clear unencrypted stored memory of sensitive data.
Java provides memory allocation through a process called garbage collection as an automatic way of handling memory management.
The garbage collector reclaims ‘garbage’ (memory that is not tagged as occupied by objects) and is no longer used by a program.
But, garbage collection is a cyclic process and, even with garbage collection, data can be exposed to an attacker.
As a result, unencrypted data should be considered as a candidate for removal by the application code.
SummaryThis was a quick run-through on a very small set of secure programming measures that the developer or technical project manager must consider.
This short list can be greatly expanded.
In a series of subsequent articles, additional topics will be presented.
This includes an overview of data sanitizing, as data sanitization of user input is another key way that attackers can exfiltrate data from an application.
The lack of proper input data sanitation, for example, can result in an SQL Injection attack in a database environment.
Other secure coding issues will be identified and addressed.
Your input, comments, and suggestions are requested.
ReferencesEnterprise, H.
P.
(2016).
HPE Security Research — Cyber Risk Report 2016, 2016.
URL: http://techbeacon.
com/sites/default/files/gated_asset/hpe-cyber-risk-report-2016.
pdf.
Zugegriffen am, 12.
ESecurity.
(2019, January 29).
2019 Cyber Security Planning Guide: Security Attack Trends.
Retrieved March 28, 2019, from https://www.
esecuritysolutions.
com/2019-cyber-security-planning-guide-security-attack-trends/McMangus, J.
(2018, June 11).
Confluence.
Retrieved March 28, 2019, from https://wiki.
sei.
cmu.
edu/confluence/display/java/SEI CERT Oracle Coding Standard for JavaMohindra, D.
, & Leung, D.
(2018, November 19).
MSC61-J.
Do not use insecure or weak cryptographic algorithms.
Retrieved from https://wiki.
sei.
cmu.
edu/confluence/display/java/MSC61-J.
+Do+not+use+insecure+or+weak+cryptographic+algorithms?focusedCommentId=88870903#comment-88870903About the AuthorDr.
Ron McFarland, CISSP, PMP is a Cyber Security Analyst at CMTC.
He is a post-doctoral scholar for the University of Maryland University College.
He received his doctorate from Nova Southeastern University’s School of Engineering and Computer Science and a post-doc graduate certificate in Cyber Security Technologies from the University of Maryland University College.
He also holds multiple security certifications including the prestigious Certified Information Systems Security Professional (CISSP) certification and several Cisco certifications.
He is a guest blogger at Wrinkled Brain Net (http://www.
wrinkledbrain.
net), a blog dedicated to Cyber Security and Computer Forensics.
Dr.
McFarland can be reached at his UMUC email: ronald.
mcfarland@faculty.
umuc.
edu.. More details