[ISN] Mainframe's midlife crisis: Security

From: InfoSec News (isn@private)
Date: Wed Feb 04 2004 - 01:52:48 PST

  • Next message: InfoSec News: "[ISN] Confirmed Email Privacy Hole at Orkut"

    http://www.computerworld.com/securitytopics/security/story/0,10801,89302,00.html
    
    Advice by Rob van Hoboken
    Consul Risk Management
    JANUARY 29, 2004 
    COMPUTERWORLD 
    
    Twenty years ago, mainframes sat in tight glass houses, accessed by a 
    limited list of select employees. Today, mainframes remain a mainstay 
    of enterprise operations. All predictions of the mainframe's imminent 
    demise have disappeared as quickly as those predicting the end of 
    brick-and-mortar retailing. In fact, industry sources estimate that 30 
    billion Cobol transactions occur daily; that's more than the number of 
    Web page hits in the same time period. 
    
    In today's enterprise, mainframes have shattered their glass houses 
    and are accessible by a variety of network services. In addition to 
    conventional users of core CICS or IMS-based transactions, large 
    organizations (including many financial services companies) are 
    shifting applications from Wintel to Linux on the mainframe to save 
    costs and increase performance and reliability. And Web-based 
    applications hosted on the mainframe's Linux or Unix environment 
    enable millions of customers to access the core transactional data 
    needed to conduct business. 
    
    With so much traffic from so many sources -- and new government 
    regulations aimed at consumer privacy and corporate diligence -- it's 
    time for companies to rethink how they secure the mainframe. 
    
    Fatigue, inexperience and overconfidence trump security 
    
    Marooned on islands, with limited outside connectivity, mainframes 
    have always been relatively easy to administer and secure. It wasn't 
    uncommon for an organization to literally have one mainframe 
    technician per user. Now, it's one technician per 1,000 users. Across 
    our customer base of more than 300 large companies, we're seeing the 
    trend: Experienced mainframe help is overworked and hard to find. You 
    can't just plug in a firewall administrator and expect him to find his 
    way around a spaghetti works of applications and services that were 
    written before that administrator was even born. 
    
    In addition to increased connectivity and staff scarcity and 
    knowledge, one of the largest challenges for mainframe security is 
    complacency and overconfidence. Most companies assume that mainframes 
    are secure, simply because of their glass-house heritage. I recently 
    visited a very large European bank that boasted about mainframe 
    security. I made the wrong assumption; with so many applications 
    hosted on the mainframe, it was relatively easy for an insider to 
    abuse and compromise the system. Sensitive data could be copied, 
    records deleted, and all traces of this activity could be removed. 
    
    In particular, mainframes are vulnerable to three major types of 
    threats: 
     
    1. Malicious data access: Hackers and trusted users have increased 
       potential to access the mainframe's core data repository just like 
       any other platform. The Sarbanes-Oxley Act, the Health Insurance 
       Portability and Accountability Act (HIPAA), the Gramm-Leach-Bliley 
       Act (GLBA) and other standards all point to the need to protect 
       data accountability and integrity. The mainframe can't be an 
       exception. 
    
    2. Self-inflicted mistakes: A generation of mainframe masters is 
       quickly retiring, and less qualified or less experienced technical 
       staffers (often rushed and overworked) can inadvertently change 
       code or settings to open up holes or deliver too much authorization 
       to the system. 
    
    3. Aged software: The strength of the mainframe is that you can 
       continue to run the old reliable software without too much maintenance. 
       But even mainframe software needs checks, patches and updates to close 
       gaps or simply improve security.
    
    Teaching an old dog new tricks 
    
    Organizations need to take a deep breath and start applying 
    traditional best-of-breed security practices to the mainframe. Here's 
    a quick checklist of the types of practices that dramatically improve 
    security on mainframes: 
    
    * Create a mainframe security dashboard: With fewer staffers on the 
      job and more threats daily, organizations need to install a mainframe 
      security dashboard to show the progress of security initiatives. A 
      dashboard should include an overview of who is accessing data on the 
      mainframe, which data groups are accessed most and, ideally, if 
      access violates your security policy. 
    
      Similarly, an overview of the number of users who have been added 
      and removed, the number of dormant accounts and the weakest passwords will 
      provide you with assurance that your mainframe security team is on 
      top of the job. 
    
    * Smart centralization: You need to better leverage the mainframe 
      knowledge base you have by wisely centralizing some of the security 
      functions -- particularly administration and auditing -- to 
      less-specialized resources. This can be done with "dummy-proof" 
      mainframe software or with enterprise systems that allow for 
      role-based and policy-driven provisioning of users and auditing of 
      file access and configurations across the enterprise. Your mainframe 
      experts should be leveraged for their expertise, while your central 
      security team and help desk should take on many of the mundane tasks 
      of auditing and administering the mainframe as they do with open 
      systems. 
    
    * Reinvigorated audits: Many customers I visit are proud of the number 
      of access violations they were able to prevent when they look at 
      log-on and data-access failures. What about those you didn't prevent 
      -- that is, the vast majority? 
    
      Make it a point to properly configure logging of the mainframe 
      operating systems and the applications on it to ensure you can 
      establish a trail of who touched what data. Then systematically look 
      at key files (data sets), particularly those governed by federal 
      regulations such as Sarbanes-Oxley, GLBA or HIPAA, and make sure 
      your policies are being enforced. Automated tools that enable such 
      monitoring allow this type of routine auditing without requiring an 
      army of administrators. 
    
    * Enhanced controls: Look to improve the security controls on the 
      mainframe. Real-time alerting for access violations or 
      misconfigurations is worth considering. You've installed such 
      intrusion-detection systems on the open system; make sure you have 
      similar confidence in your mainframe security. Similarly, ensure 
      that you have solutions that can prevent the mistakes that will be 
      made by the less experienced and less technical staff that you'll 
      need to employ to pick up the administrative burden of the 
      mainframe.
    
    Finally, ensure that your administration and audit functions are 
    indeed separate and serve to check and balance each other. 
    
    Even though security threats to the mainframe may not be as glamorous 
    as well-publicized viruses and worms, they are indeed a viable threat 
    to the mission-critical services and information typically found in 
    the glass house. The good news: Technologies for monitoring security 
    have come a long way, and even the simple measures outlined above can 
    have a dramatic affect on mainframe security without requiring a 
    fortune in staff or software. 
    
    You can teach an old dog new tricks. You just need to try. 
    
    
    
    -
    ISN is currently hosted by Attrition.org
    
    To unsubscribe email majordomo@private with 'unsubscribe isn'
    in the BODY of the mail.
    



    This archive was generated by hypermail 2b30 : Wed Feb 04 2004 - 04:38:36 PST