EIM Security Strategies – Have you really secured your organization’s enterprise information assets?
By Mike Jennings
Security threats exist against your enterprise information assets, whether it is accessible through the Internet or buried deep within your internal network available only to authorized users. Today’s applications compound this increasing threat by spanning the enterprise infrastructure and the Internet. Vendors supplying applications for IT environments are being pressured by users to quickly provide more functionality and performance to the marketplace to outpace the competition, while sacrificing security. Many information system administrators believe that properly controlling and maintaining user 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, such as base64, do not provide the same security as encrypting and can easily be reversed engineered to reveal contents. Another example is delivery application’s that allows 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 interconnected 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. This leaves other possible avenues of exploitation to your IT environment and its information resource unless configurations are modified to maximize security.
Often, the groups in a company, who are qualified to evaluate applications and infrastructures 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 your application implementation has been through an internal or external security vulnerability assessment, any change to any underlying support components requires notification to appropriate support personal for analysis of the modification, and possible security effect to the overall infrastructure. Increasing use of messaging, SOA, and wireless functionality in EIM applications will provide additional points of possible exploit against your organization’s enterprise information.
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.
There are measures that you can be utilizing to help minimize or remove security vulnerabilities in your EIM 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.
Remove or at least turn off features and functionality of an application that are not being 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 is not going to 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 which DBA at which 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. If you do not already 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 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.
The mitigation methods described so far were all application specific and important to guard against. 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 then the risk is still high that attacks will succeed against it. Make sure you follow your application vendors’ instructions on how to secure your 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 your 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.
Once a thorough understanding of the security vulnerabilities of the IT environment is achieved, a reality check needs to occur. You cannot ensure 100% security of your IT site unless you have unlimited funds and time. The complexities and interdependencies of today’s information technology environments, software, and infrastructure make the testing of every possible permutation virtually impossible. Imagine performing code reviews of your 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.
About the Author
Michael Jennings is a recognized industry expert in enterprise information management, business intelligence/data warehousing and managed meta data environment. He has more than twenty years of information technology experience in government, manufacturing, telecommunications, insurance, and human resources industries. Mike has published numerous industry articles for DM Review and Intelligent Enterprise magazines. He has been a judge for the 2002 - 2007 DM Review World-Class Solutions & Innovative Solution Awards and 2003 Wilshire Award for Best Practices in Meta Data Management. Mike speaks frequently on enterprise information/architecture issues at major industry conferences and has been an instructor of information technology at the University of Chicago's Graham School. He is a co-author of the book “Universal Meta Data Models” and a contributing author of the book “Building and Managing the Meta Data Repository”. He may be reached at MJennings@EWSolutions.com