2010 GSE Security Journeyv2 - Bitly

®

IBM Software Group

The IT Security journey: It’s not where you are going, it’s how you get there April 2010

T.Rob Wyatt, WebSphere MQ Security Focused Practice [email protected] http://ausgsa.ibm.com/~trwyatt/ (internal) or http://t-rob.net (public) IBM Software Services for WebSphere http://www.ibm.com/WebSphere/developer/services last update: March 3, 2009

IBM Software Group | WebSphere software

WebSphere MQ Security Presentation Series This presentation is part of the WebSphere MQ Security Presentation Series led by T.Rob Wyatt with help from so many others Available internally at http://ausgsa.ibm.com/~trwyatt/public/wmqsecurityseries/

Related presentations We assume you’ve seen or are familiar with

• • •

Core Concepts (From the WAS Security Presentation Series) WMQ Security Introduction Authorization Overview

You may be interested in

•

WAS Security Presentation Series available internally at http://pokgsa.ibm.com/~keys/documents/securitySeries

Materials may not be reproduced in whole or in part without the prior written permission of IBM

2


Change is the Only Constant This presentation reflects My current opinions regarding WMQ security Products continue to evolve (even in PTFs) This will be revised over time Your thoughts and ideas are welcome


3


Security is the journey, not the destination I’m going to build a secure system!

Wonderful! What will it do?

In your journey, the business function is the destination. Security is whether and in what condition you arrive. Materials may not be reproduced in whole or in part without the prior written permission of IBM

4


Agenda

Why not a destination? Event detection Incident response Timely application of maintenance Maintain knowledge currency Periodic verification and testing Recovery Forensic analysis Continuous security improvement


5


Why is security not the destination? If security is regarded as a one-time configuration task, or as something that can be “switched on” after the functional requirements have been implemented, then it becomes difficult or impossible to achieve the desired design goals. Whatever level of security is achieved is likely to then degrade over time as attack methods evolve, unless the system is subject to ongoing reevaluation and maintenance. Effective security is an iterative practice that begins with system design, is integrated into software development life cycle, is practiced throughout the implementation phases and then becomes part of post-production operation.


6


Why is security not the destination? Risk = Asset / (Threat * Impact * Probability) None of the factors in the equation remain constant over time. As the asset value – what the information involved is worth – changes, the cost/benefit of the security controls changes as well. Best to operate on the assumption that new threats will be discovered. The impact of an incident to a particular system may change due to internal factors such as growth or to external factors such as regulation. Probability can increase as attack technology improves and with the rise of target value over time, among other things.


7


Why is security not the destination? Many of the mitigations are run-time activities rather than build-time configurations. Examples: Vulnerability scans Real-time incident monitoring Continuing formal and informal education Vendor announcement monitoring Patch application These indicate that security is not a static state of the system but rather an iterative discipline implemented as an ongoing practice.


8


Case Study #1 – Security event detection A large manufacturing firm secured administrative access and applied role-based access control to their WebSphere MQ network. At our suggestion, they enabled authorization events. Result: Roughly 10,000 authorization failure events per day had been occurring undetected. Although the root cause was an issue with the tooling, the sheer volume of events made it impossible to detect any legitimate security events that might have been generated.


9


Security event detection The products which comprise the application and messaging network all produce logs, console messages or other event notifications. These serve Both as early warning and real-time detection mechanisms. In addition to The built-in notifications, purpose-built products exist specifically to detect and report security-related events. Recommendations: Use the capabilities built into the products you have. For example, with WebSphere MQ, enable events and monitor the event queues. With WebSphere Application Server, monitor the server logs and/or configure email notification. Consider the extent to which dedicated security monitoring tools are required. For example, Tivoli agents can monitor MQ event queues and log files for MQ, WAS, the underlying OS, etc. To the extent possible, eliminate “nuisance” events through proper configuration rather than filtering.


10


Case Study #2 – Incident response

Large US bank had grown by acquisition Variety of overlapping administrative teams Very large constituency of users and stakeholders The same security issue independently found and fixed by some, but not all, of the administration teams. Users and stakeholders, including affected applications, only haphazardly notified. Results: Best case is that critical applications are exposed to known vulnerabilities longer than is necessary. In the worst case, latent vulnerabilities become permanently embedded in the system.


11


Incident response In the event of a security-related event, it is helpful to have in place a defined incident response plan. The plan helps to insure that all stakeholders are notified in a timely manner and that the response is coordinated. Recommendations: Develop and maintain a written, formal incident response plan. Ensure that access to applications and systems is traceable to an owner, whether that is a team or individual. Identify additional stakeholders who do not access the system directly. Train personnel to recognize and report security-related events and to understand their role in reporting and/or resolving such events. Implement a system whereby stakeholders are notified of securityrelated events and subsequent activities. Test the incident response plan periodically.


12


Case Study #3 – Timely maintenance

Large US personal/commercial insurance company failed security audit. Systems installed with then-current versions and never updated. Some systems on versions out of support by as much as 10 years! Vulnerabilities discovered in end-of-life software remain unfixed.

Result: Impossible to secure the old versions. Had to upgrade the entire messaging network and all of the systems built on top of it. Years of deferred maintenance all rolled up into one large project. Coordination of all interdependencies and regression testing the entire application code base significantly added to the cost. Massive diversion of resources from new function delivery.


13


Timely maintenance Vendor security patches are only effective when applied! It is important to maintain the ability to apply these patches quickly upon their release. This involves deployment and testing in lower environments prior to production release in most cases. Recommendations: Allow for application of security patches during the software development lifecycle. Don’t force an urgent patch to wait for the next planned release of your application. Take advantage of automated testing. For example, with a WebSphere MQ application you can create a set of messages that test all the various code paths and functions, then save those messages to a file and replay them at will. Use automated deployment where possible. For example, with WebSphere MQ installation of the base product or Fix Packs can be scripted using the silent installer. Be aware of compliance requirements. For example, the PCI Data Security Standard calls for application of security patches in 90 days. Materials may not be reproduced in whole or in part without the prior written permission of IBM

14


Case Study #4 – Maintaining knowledge currency US Financial Management firm had applied administrative hardening, SSL, and role-based access control to their messaging network. There was nobody on the admin team whose job included the responsibility to subscribe to and review vendor security notices. Result: The system contained vulnerabilities that were generally well-known but unknown among the administrative team within this organization. They were quite surprised when our penetration test quickly gained complete control of their target systems.


15


Maintaining knowledge currency It is essential for project, operations and administration personnel to keep up-to-date with security developments in their specialty and industrywide in order to respond to changing threats and take advantage of improved defense mechanisms. Recommendations: Subscribe to vendor announcement lists to receive notification of security-relevant updates and news. (Example: search on “My IBM” for subscription and RSS feeds specific to your country.) Participate in the online communities dedicated to specific products that you use and related security topics. Take advantage of formal training to enhance security skills. This may include classroom training, instructor-led online, self-paced courses, webinars, conferences or any number of other delivery methods. Formalize this as a line item in job descriptions rather than relying on initiative of personnel on an as-available basis.


16


Case Study #5 – Periodic verification and testing A well-known European bank established a Center of Excellence which produced a set of Best Practices for securing applications. The guidelines were tested thoroughly, implemented and practiced for many years. Account administration policy changed, rendering the security ineffective. Legitimate accounts were inadvertently granted full administrative rights. Because the security roles were never retested, the over-authorization accumulated over a period of eight years. Result: The bank failed audit and systems representing eight years worth of application development needed to be retested.


17


Periodic verification and testing During operation of a system, the positive constraints of the system are always being tested – a user denied access will open a support ticket. But the negative constraints are rarely tested with the result that overauthorization often goes undetected. Recommendations: Test and periodically retest the negative constraints of the system beginning early in the SDLC and in production. Using SSL as an example, verify that… Requests presenting revoked certificates are refused access. The certificate is not honored for access paths other than those specified (i.e for WebSphere MQ that the certificate is not accepted for an administrative SVRCONN channel). The trust store contains only those certificates and certificate authorities that are legitimately trusted. That users with an untrusted certificate or no certificate are refused access.

Be prepared to similarly test or verify authentication, authorization settings, access controls, etc.


18


Case Study #6 – Recovery A large US bank experienced a DOS when a vendor’s application looped while trying to connect and initiated connection requests at a sustained rate of about 1,000 per second. The same WebSphere MQ listener was used for all external and internal connections. Results: No new connections were possible, either for applications or for administrators. As existing connections timed out, additional applications were impacted. A sustained outage occurred during the time it took to contact the vendor and for them to resolve the problem.


19


Recovery Good intrusion detection provides assurance but no guarantees. Operate on the assumption that the system will be compromised and provide the means to recover the system to an operational state. Bear in mind that compromise is not always by a deliberate attack but may result From a combination of human error and over-authorization. Recommendations: Use risk assessment and threat modeling to understand the ways in which a given system may be compromised. Consider how to restore a compromised system to a functional state after an incident. Consider how data may be recovered following an incident. This may include anything from automated reconciliation to manual analysis and recreation of transactions. Set Recovery Time Objectives and verify through simulations, drills or live recovery exercises that you can meet these. Prioritize the applications accessing a given system and consider whether a graduated return to service is appropriate. Materials may not be reproduced in whole or in part without the prior written permission of IBM

20


Case Study #7 – Forensic analysis During an outage at a media services company, it was observed in real time that changes were being made to the system by someone other than an authorized administrator. The security design focused primarily on intrusion prevention and included an implicit design assumption that this obviated the need for intrusion detection and analysis. Extensive security configuration had been applied, including SSL access for administrators and applications. Results: It was impossible to determine who was responsible for the changes. No information about the changes was captured for later analysis. The company was glad that the unauthorized user was friendly.


21


Forensic analysis Forensic analysis capability is important to prove accountability in an audit and also after an incident to track down the root cause, assess impact and possibly prosecute an attacker. Recommendations: Build in accountability beginning with the system architecture and design, at a level above product configuration. For example, it may be helpful to provision separate access paths for different roles. Be familiar with the configuration, logging and auditing features of the hardware and software systems involved so that you know in the design stage what capabilities are present and the cost to implement and operate them. Understand any internal and external compliance that may specify the minimum baseline configuration requirements (example: PCI DSS). After implementation, verify that the configurations and tools provide the necessary levels of traceability and accountability.


22


Case Study #8 – Continuous security improvement A global retailer executed security remediation as a one-time project. No provision was made to measure or track security indicators. After failing an audit a few years later, it was determined that another large remediation project was required. Results: Large-scale remediation projects that were disruptive, expensive and unexpected. Opportunity cost due to diversion of resources away form other projects.


23


Continuous security improvement Recommendation: Establish Key performance Indicators and Key Performance Metrics, then measure and track progress. KPI

Metric

Improvement Trend

Target

Time between release of vendor security patch and full deployment.

Number of days

Decreasing

90 Days as per PCI standard

Percentage of nodes in compliant with baseline configuration specification

Number of nodes as reported by automated scans

Increasing

100%

Length of time that a node is out of compliance with the configuration baseline

Number of days

Decreasing

14 Days

The examples above are not meant to be taken as specific guidelines. Each shop must determine which indicators are useful in a given context, then provide for measurement against the metrics, set performance objectives, track progress and periodically reevaluate.


24


Summing up… The best way to build a road to ineffective security is to build a road to security! The destination, your ultimate goal, is the business function that serves your customers and makes a profit. Security is the risk management that is practiced from throughout the journey that helps you arrive safely. Security is an iterative practice that touches all IT disciplines and works best when integrated deeply into the culture of the enterprise. Security is the journey. Materials may not be reproduced in whole or in part without the prior written permission of IBM

25


Question and answer period


26


Appendix


27


References IBM Redguide – Security in Development: The IBM Secure Engineering Framework http://www.redbooks.ibm.com/redpapers/pdfs/redp4641.pdf My IBM – Go to http://www.ibm.com for your country and click on “My IBM.” From there you can subscribe to notifications for all IBM products. IBM X-Force security alerts – go to http://xforce.iss.net/ and search by product or subscribe. IBM Security Solutions – http://www-03.ibm.com/security/


28


Resources IBM Worldwide Training – http://bit.ly/IBMTraining or http://www-304.ibm.com/jct03001c/services/learning/ites.wss/zz/en?pageType=page&c=a0011023

IBM Events – http://bit.ly/IBMEvents or http://www-304.ibm.com/jct03001c/services/learning/ites.wss/zz/en?pageType=page&c=a0002173

IBM developerWorks Security – http://www.ibm.com/developerworks/security/ Annual Tivoli Pulse conference – http://www-01.ibm.com/software/tivoli/pulse/ Annual IBM IMPACT conference – http://www-01.ibm.com/software/websphere/events/impact/


29


Legal © Copyright IBM Corporation 2010. All rights reserved. IBM, the IBM logo, the e-business logo and other IBM products and services are trademarks or registered trademarks of the International Business Machines Corporation, in the United States, other countries or both. References in this publication to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. Product release dates and/or capabilities referenced in this publication may change at any time at IBM’s sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future product or feature availability in any way. Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries or both. Microsoft, Windows, Windows NT and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries or both. All other trademarks, company, products or service names may be trademarks, registered trademarks or service marks of others.


30