Every organization needs a variety of security strategies for all areas of enterprise data management, with responsibilities assigned to business and technology teams
Security threats exist against every enterprise’s information assets, whether it is accessible through the Internet or buried deep within an internal network available only to authorized users. Current applications compound this increasing threat by spanning the enterprise infrastructure and the Internet. Vendors supplying applications for IT environments are pressured by users to provide more functionality and performance to the marketplace to outpace the competition, while sacrificing security. Data management best practices should address data security in areas such as data governance, metadata management, master data management, data integration, etc.
Challenges in Application System Administration
Many information system administrators believe that properly controlling and maintaining user activities and access privileges of the information system applications alone provide adequate security. Commonly, these applications, built or bought, were evaluated primarily based on providing functionality and performance, not security. For example, some information system applications still employ encoding techniques in their URL strings and/or header variables to prevent unauthorized access. Encoding methods do not provide the same security as encrypting and can easily be reversed engineered to reveal contents. Another example is delivery applications that allow application information to exist in a persistent state on the hard drives of a web server as an unencrypted cache or temporary file. This data is used to increase performance response of recurring user requests to the application at the expense of security. This also applies to the supporting components of the infrastructure (web, application, database servers) which are connected through the IT infrastructure. These components are typically shipped by vendors to provide the most functionality out of the box, not necessarily the most security. Doing so leaves other possible avenues of exploitation to an IT environment and its information resource unless configurations are modified to maximize security. Often, these specific modifications are never made.
Often, the groups in a company who are qualified to evaluate application and infrastructure implementations for security are excluded from the decision process until the application is about to go into production. In the best case, this can lead to delays in implementation or redesign due to security risks. Worst case, due to insufficient time for security analysis, implementations go live without fully recognizing the possible compromise that has been made to enterprise information from the application. Even if the application implementation has been through an internal or external security vulnerability assessment, any change to any underlying support components requires notification to appropriate support personnel for analysis of the modification, and possible security effect to the overall infrastructure. Increasing use of messaging, SOA, and wireless functionality in data-intensive applications will provide additional points of possible exploit against an organization’s enterprise information.
Exposure
The most common application vulnerabilities found in data-intensive applications, involves input validation. How well an application defends itself against malicious or erroneous user, input directly correlates to its level of susceptibility and ease of exploit. Often the first activity an intruder will perform is to look for information leakage, i.e. any clue that could help in mounting a successful attack. The most obvious place to look is in web pages. HTML and JavaScript comments often reveal useful information such as application version numbers, hidden variables, code, or links that have been commented out but still function if exploited. For example, one product reveals the full directory path where data files were stored, enabling an attacker to use another exploit to download them directly, bypassing application-level checks.
Parameter manipulation is a rather broad description of a very simple fact: every piece of information and every parameter sent by the browser to the server can be tampered with. In its simplest form, the parameters changed are typically found in URLs. One of the most notorious security attacks results in an attacker’s ability to execute code, typically JavaScript, on another user’s browser.
Many enterprise applications allow users to directly or indirectly enter SQL queries. Often, applications that do not support SQL queries are designed to append a user’s input to SQL queries directly. Both of these actions can create an opportunity an attacker needs to perform SQL injection. SQL injection attacks find ways to insert SQL code into applications in order to gain control of a system. Actual SQL may not be the only code executed on the database. Many of today’s DBMSs have a whole host of stored procedures and other features installed by default. Some even enable running an executable already present on the database server itself, which can lead to further exploits.
Application-Specific Security Risk Mitigation
There are measures that can be used to help minimize or remove security vulnerabilities in many data-intensive applications. Securing the IT environment is more than just administering users and access privileges. There are a number of actions that can be implemented with varying levels of effort to mitigate security exposures of enterprise information resources. Including groups such as data governance, metadata management, and other data management functions can help expand the discussion to ensure adequate attention to data security risk management.
- Remove or at least turn off features and functionality of an application that are not used. This will reduce the number of access points that an attacker can take advantage of and manipulate. The more access points the more opportunities for exploitation. This includes any sample code provided by an application vendor, debug functionality used by developers, and administrative functionality that will not be used.
- Place controls on who has access to the various infrastructure components. Minimum access should be given to meet the business needs for a specific user’s role. For example, only a limited number of database administrators (DBA) should have full access to the all enterprise information stores. Even then, access logging should be in place to capture what actions were performed by each DBA by date and time for auditing purposes.
- Assess the security of data and communications flow between the application and the infrastructure plus the application components. Data coming into a site may be secured under a secure socket layer (SSL) and then sent in clear text or simply encoded between application components. Make sure the authentication services use encryption when accessing entitlements stores (e.g., LDAP).
- Monitor the usage of the application site for variation in patterns. Unusual usage patterns may be an indication of an attack and worth investigating.
- Review how the application stores data extracted from the enterprise environment. Ideally, data should not exist in a persistent form on disk anywhere in the environment except in a properly secured database or data store. If persistent application data must be present on disk, it should utilize additional security defenses such as network segmentation (e.g., firewalls) or encryption to limit any exposure threat.
- If the site utilizes a single sign-on (SSO) application for controlling access and authentication between application components, determine if it has a cross-site scripting option to further deter this particular type of vulnerability.
- Develop and use a software development security standard for all internally and externally developed application code. For those who do not have a security standard, search on the Internet for security sites that provide white papers and guides on best practices for building secure applications.
- Correct any information leaks found in applications that provide application, security, or infrastructure information. Error and security messages from applications and databases often provide useful information on servers, networks, directory paths, filenames, programs & scripts, tables, and other infrastructure items. This information by itself may seem relatively benign but when combined with other techniques can lead to exploits.
- Insure that enterprise applications manage the security of sessions typically using cookies when a user logs out. A user’s cookie or other session credentials should be invalidated to avoid session hijacking.
- Subscribe and/or monitor vendor and security web sites and user groups for security alerts.
Server-Level Security Risk Mitigation
The mitigation methods described above were application specific and should be an important part of any organization’s risk mitigation plan. However, security does not stop there. Even though an application may be secure, if it is running on a server that has not been hardened, the risk is still high that attacks will succeed against it. Follow the application vendors’ instructions concerning securing server software. If the vendor does not provide this information in the documentation, be sure to check their Web site or contact their technical support team.
Another option is to engage a third party digital security consulting firm to conduct a security audit of the IT environment. The assessments can be in the form of an application penetration test to a vulnerability assessment of the front-end applications. The vulnerability assessment focuses on the risk posed by transaction based exposures to the front-end applications (e.g., cross-site scripting, information leakage, input manipulation, many others). The application penetration test assesses the application site’s ability to resist attacks from both valid and anonymous users. This is accomplished by testing the site’s ability to prevent data manipulation, privilege promotion, and authentication bypass.
Conclusion
Once a thorough understanding of the security vulnerabilities of the IT environment is achieved, it is time for a reality check. No security plan can ensure 100% security of an IT site without unlimited funds and time. The complexities and dependencies of information technology environments, software, and infrastructure make the testing of every possible permutation virtually impossible. Imagine performing code reviews of all the third-party enterprise applications looking for security vulnerabilities. Choices can be made to resolve the exposure immediately, defer fixing, have vendor remediate, or manage the risk. Business and security need to team together to assess the real level of risk, probability of business disruption, business liability, and cost of remediation before proceeding down any path.
