WikiLeaks – Could It Happen To You?

For enterprise IT managers and security professionals, the on-going WikiLeaks disclosures underscore the information security gaps that exist even when common security controls are in use by large organizations.  It is not necessarily the controls themselves that are flawed, but more often the supporting processes and procedures that were quickly pulled together under pressure, and seldom if ever revisited or audited at a granular level for optimal performance and completeness.

This entire ordeal also serves to highlight the importance of adopting a “trust, but verify” approach to hiring practices and access control.  This means that you need to be just a little bit more paranoid regarding your practices, without distrusting your employees.  Remember that everyone that you hire is human, and that people will make mistakes if mistakes are possible.  They are (hopefully) hired due to their capabilities and experience, but what really separates them from the other candidates that showed up for an interview?  Were you able to validate their claims of reliability and trustworthiness?  Trust that they will exercise good judgement, work towards corporate betterment, but verify that each access to sensitive data or corporate intellectual property is properly justified.   Remove the temptation to go astray, and by all means, let them know that you verify.  Your intentions are to DISCOURAGE criminal or damaging behavior, not ENTRAP those who may err or fall prey to social engineering.

What controls should be in place?  That depends on the type and classification of the information that is at risk.  When it comes to client financial and personal information, it is clear that monitoring, notification and escalation controls are a requirement.  Take a lesson from PCI, even if you don’t adopt it formally.  The PCI DSS is simply basic computer security.  A quick review of the 12 main PCI requirements shows nothing revolutionary, and they offer a solid starting point for virtually any security compliance engagement. 

The following are the 12 PCI DSS requirements:

  1. Install and maintain a firewall configuration to protect data.  (Note that there are no “PCI-compliant firewalls”.  This requirement is intended to ensure that companies put a firewall configuration policy in place, and develop a configuration test methodology.  The firewall must be configured to protect card holder data.)
  2. Do not use vendor-supplied defaults for system passwords and other security parameters.
  3. Protect stored data.
  4. Encrypt transmission of card holder data and sensitive information across public networks.
  5. Use and regularly update antivirus software.
  6. Develop and maintain secure systems and applications.
  7. Restrict access to data by business need to know.
  8. Assign a unique ID to each person with computer access.
  9. Restrict physical access to card holder data.
  10. Track and monitor all access to network resources and card holder data.
  11. Regularly test security systems and processes.
  12. Maintain a policy that addresses information security.

These requirements are not rocket science, and are not very prescriptive in how to go about attaining PCI compliance.  That is by design.  There are many, many ways to go about accomplishing each task, and each business can proceed to find the method that best serves their technical, business and cultural needs.  Some of the more granular recommendations commonly made to assist in that endeavour focus on:

  • Organizational Security (Background Checks, Training, Certifications)
  • Mature Software Development (SDLC, upgrade cycles in line with PA-DSS)
  • Product Vulnerability Management (App detection tests and Code reviews against common vulnerabilities & weaknesses)
  • Secure Implementation (Contractual PA-DSS requirements, Enforcement of secure installations)
  • Emerging Payment Technologies (Adhere to field encryption, token, and PAN elimination, support future dynamic solutions)
  • Formalize Processes & Procedures (Write the process execution steps down, and measure your execution)

The following list doesn’t detail all the best practices for PCI compliance, but executing these steps will ensure any PCI project runs much smoother, and can be implemented and expanded upon to enhance the security posture of any organization.

  1. Examine Physical Security
    • Ensure appropriate physical security of systems and associated peripherals.
    • Verify that there is no unauthorized physical access to sensitive systems.
    • Look for “unthought of” access means (pony-walls, vents, drop ceilings, etc.)
  2. Perform a Gap Analysis
    • This is the natural starting point for any PCI endeavor.
    • The PCI Self-Assessment Questionnaire from the PCI Security Standards Council should be completed.
    • After the SAQ is done, you should have a fairly good idea of which controls and tools are in place and which are not.
    • The SAQ is divided into 6 sections, each focusing on a specific area of security based on the DSS requirements.
    • Determine whether each requirement is adequately addressed for every in-scope system.
    • Evaluate firewall rules independently and in-whole for logic/routing issues.
  3. Perform Asset Discovery
    • Map your internal network.
      • Enumerate all Ingress & Egress points within your environment.
      • Enumerate all PCI segments.
      • Discover all assets (PC, Infrastructure, Servers, etc.)
    • Enumerate all assets discovered for platform and Operating System.
    • Enumerate all software installed on assets.
    • Scan assets for known O/S, software and configuration vulnerabilities.
    • Focus remediation efforts first on Internet facing systems and applications and work inwards.
    • Assess the risk presented by each vulnerability and the work-load to remediate.  Tackle the worst, first.
  4. Develop Policies/Processes/Procedures
    • Establish policies, processes and procedures to limit the storage and retention time of PCI data.
      • Classify data according to its type and sensitivity.
      • Set up backup and retention policies based on the data’s classification.
      • Setup a restoration test schedule to ensure that your backups are working.
      • Develop Incident Response Process and Incident Handling guidelines.
    • These concepts should be taken further into the organization later to reduce other data related risks.
  5. Create a Data Encryption Process
    • Far too many businesses send unencrypted credit card data via e-mail or other means. 
    • Encrypt data: 
      • At rest, in readily accessible storage.
      • In transit, being sent across the wire.
      • Offline, on tape or other media.
  6. Discover Data
    • Know exactly where all your PCI relevant data is.
    • Identify all payment acceptance channels, data flows and locations where PCI data is stored.
  7. Eliminate Track Data
    • Merchants are prohibited from storing track data.
    • Track data is the information encoded within the magnetic strip on the back of a credit card, which is read by a point-of-sale (POS) system. 
    • Some POS systems have been collecting track data without the merchant knowing. 
    • Hackers know what POS systems store this information and will target retailers who use that system.
  8. No Unsecured Wireless
    • Do not use unsecured wireless networks to transmit sensitive data.
    • Do not use a weak wireless encryption technology.
  9. Modify POS Devices 
    • Ensure that POS devices are not storing full card data, especially Card Validation Value/Code.
    • The full 16-digit credit card number should never appear on any hard copy output.
  10. Implement Security Awareness & PCI Training
    • Not every staff member needs to be a PCI qualified security assessor (QSA), but they do need a formal training program on what they have to do to ensure they are handling credit card data in a manner that supports the PCI requirements.
    • Including IT and Security staff in these training courses will increase the understanding of and compliance with PCI.
    • Educate staff regarding PCI requirements and internal policies.
  11. Implement & Enhance Logging & Monitoring
    • Increase logging and depth of logging details on critical systems.
    • Monitor transactions on critical data, including who looked at it, when they looked at it, and if it was printed or copied.
    • Implement a log file server to replicate and consolidate logging to aid in investigations.
      • A classic attempt to cover ones tracks involves the corruption or tampering of logs.
      • If the local log is your only evidence, and an attacker has admin access, you have no evidence.
      • If you don’t already have IDS, IPS or DLP, plan and deliver your implementation NOW.
    • Monitor logs for specific, documented indicators.
    • Activate Incident Handling guidelines for every trigger event.
    • Regularly review security and audit logs.

The gaps in information security that likely led to the disclosure of classified information to WikiLeaks could easily turn up in any corporation, large or small.  Even if information is appropriately classified and stored to an appropriate level, access to information requires effective monitoring.  That very last item is the point that makes the difference between a successful security program and just another untapped information collection.

Sounds like a big exercise?  You bet it is.  Is it worth it?  I can’t objectively answer that for you, better ask your customers…


One thought on “WikiLeaks – Could It Happen To You?

Comments are closed.