Release of Symantec source code leads to ‘uninstall’ recommendation

Symantec was the victim of an attack where its source code for most major products protecting consumers and enterprises around the world was breached.  This attack occurred in 2006 and the source code has been available to parties to leverage for attacking businesses, individuals, and governments since that time.  Recently, by the accounts recorded so far, Anonymous gained access to this stolen source code and is now threatening to release it – either generally or for a fee to those who would find value in it.

The result of this has lead Symantec to state in their Security recommendations whitepaper to uninstall or disable the PC Anywhere application.  This is a critical application for most, so such a recommendation is quite difficult.

There are a number of issues and risks that arise here that will likely be an ongoing list:

• The source code was lost in 2006, so one can infer that this attack vector and every install was at risk to this attack for the past 6 years
• The presence of source code being released does not in itself create an attack vector – example is how public cryptography is tested openly and the immense use of Open Source software.  In this case though, the release progressively escalated the risk from “increased risk” to “uninstall” now risk
• Other major enterprise security applications were also stolen, do the same risks exist and are forth coming?

Symantec is an important security provider, as their systems are installed on a 100+ million end points globally and their PC Anywhere solution provides direct access to global companies.

Given the velocity of updates related to Symantec’s breach, I would offer for discussion the following takeaways:

• There is no silver bullet to be secure and solve this single breach issue in the customer’s of Symantec, so a process must be established
• Review the activity of your firewalls, behavioral analysis systems, and such systems to determine if you have been attacked through this attack vector … over the past 6 years (deep analysis of the Symantec application is in order – the “authorized and approved” connections activities, not just the failed attempts)
• Focus on your programs of complicating the intruder to your system – a great case here … if a malicious user had access to your network what could be done.  This question should provide a substantial return in minimizing this type of breach of trust in the security model.  Similar cases should include Microsoft remote tools, operating system, and other infrastructure high install base applications.

Below are references to the article, paper, and Symantec’s update page.

• Here is an article on the recommendation to remove PC Anywhere from Computer World
• Here is the whitepaper referenced in the article with additional tips (PDF)
• Here is Symantec’s update on patching the applications.

This impacts all secure environments – PCI and other systems that are depended upon.  Perhaps the attack is not intended to modify or damage a system, but for corporate espionage and such.  Strong practices and a aggressive risk assessment review cycle is in order – such as ISO 27001 ISMS (done correctly and maturely).

Thoughts?  Corrections?

James DeLuccia

Vendor Proof of Security, GSA Final Rule and how it can help everybody else

The GSA Final Rule got a lot of attention in the government services sector as it solidified the requirements related to security and third parties.  The Final Rule makes it clear that upon winning a contract and to continue the contract ongoing performance and attestation is required of the Security program.  Specifically the language states the following:

“…the rule requires contractors, within 30 days after contract award to submit an IT Security Plan to the contracting officer and contracting officer’s representative that describes the processes and procedures that will be followed to ensure appropriate security of IT resources that are developed, processed, or used under the contract. The rule will also require that contractors submit written proof of IT security authorization six months after award, and verify that the IT Security Plan remains valid annually. Where this information is not already available, this may mean small businesses will need to become familiar with the requirements, research the requirements, develop the documents, submit the information, and create the infrastructure to track, monitor and report compliance with the requirements.”

While the idea of 3rd party audits and attestations is common practice in the private sector, there are a few interesting considerations that businesses should consider adopting as appropriate based on the type of vendor.

“…ensure appropriate security of IT resources that are developed, processed, or used under the contract…”

Businesses when setting up agreements with third parties should be engaged at the relationship discovery stage and upon contract.  Specifically architect what are the appropriate security safeguards for the type of vendor and what will be the scope of processes of the vendor.  This is becoming more present across the spectrum of industries, but the maturity of the above process is just emerging in mature organizations.

“…verify that the IT Security Plan remains valid annually…”

Business relationships must be managed.  Operational and performance metrics exist for each vendor and if a vendor misses a contractual agreement, there are usual fines and contract adjustments that result.  The management of vendor operational information security to the agreed upon plan should also be executed.  This is a great opportunity to establish a routine, efficient, and appropriate validation / attestation process.

The takeaway here is that the practices securing businesses must evolve to address the introduced risks of third parties.  There is a need to be balanced in the requests to vendors and so a progressive security plan that reflects the relationship is appropriate.

InfosecIsland has a nice writeup of the full GSA Final Rule here, and the actual rule is available here too.

Other thoughts / Considerations?

James DeLuccia

//cc at IT Compliance and Controls

Would you be PCI Compliant if there were not fines, fees, damages? Possible result of court case

An interesting thought exercise is would businesses be compliant with an industry standard, such as PCI DSS, and regularly evaluate their security posture against this standard if there was NO fines, punishments, or financial liabilities present?  Would organizations secure and establish the same safeguards, better safeguards, or let the environments float away out of a compliant posture?

These are the questions that comes to mind when reviewing the counter-lawsuit of the Utah Merchant against U.S. Bank claiming that the financial institution wrongfully seized money from their account.  The money ($10,000) was seized to pay part of the $90,000 fine that Visa and MasterCard imposed on the establishment.

The case put forward by McCombs is summed up nicely by Wired – Threat Level, and vocalizes some of the complaints heard globally that PCI …

“force[s] merchants to sign one-sided contracts that are based on information that arbitrarily changes without notice, and that they impose random fines on merchants without providing proof of a breach or of fraudulent losses and without allowing merchants a meaningful opportunity to dispute claims before money is seized.”

What is interesting here is that … through forensic review the Merchant systems were proven to not have (likely) been breached, but Visa and MasterCard actually fined the Merchant $1.33 million for being non-compliance (a result of having used 2 of the 6 approved forensic firms).  Ultimately the fines were reduced.  An additional interesting bit is 2 banks stated they incurred losses as a result of CPP (Common Point of Purchase) breach sourcing technique.  This added about $13k additional fines.  Despite no evidence being provided.

This is a unique example where the correctness of passing liabilities to merchants and members of the payment card universe will be challenged.  As a result the entire underlying Payment Card Data Security realm too.

Businesses of course have incentive to protect customer data, but to what extent and when the liability moves up to the payment gateways, banks, and card brands – how will practices change?

There are great examples of standards that are created collaboratively (NERC CIP pre-Energy Act Law) and adhered to, but there are many where standards exist without true adoption and success.

What will the protection of sensitive card data look like in the near future?  How will information security programs evolve when there is no mandate?  A lot of questions to consider moving forward.

Thoughts?

James DeLuccia IV

 

When vendors attack, inspired by India espionage reports of USCC and Symantec

The attacker victim scenarios we designed are no longer appropriate.  It is amazing that no less than a decade ago I was working with teams to design information security attack scenarios where we were dealing mainly with mafia, ex-intelligence agents, and loose nit groups.  Now we have countries organized and attacking with some brilliant attack strategies.  The sophistication, coordination, and execution of these is obvious to be conducted by military / intelligence professionals.  Despite all the conjecture it has been difficult to prove, as usually only victims and logs stand as evidence.  The developments of YamaTough present a hard case where a countries espionage activities may be exposed.

I would encourage reading the multiple great articles on this topic, a superb starting point is InfoSecIsland.  The facts are critical to understanding how to protect company, personal, and government assets.  The actions are key to understanding what is at stake, and how critical it is to be ever agile to these threats.

A takeaway from this attack and the article referenced above though are not to be more agile.  It is encouraging a deep evaluation of the third parties in which you do business.  This evaluation must consider every partner with the business that gains digital access to company resources.  Who should this include, well at least the following:

• Vendors that maintain your systems (hardware and software)
• Outsourcing teams that manage remotely management / operational support of your systems
• Vendors that support your Cloud environments
• Vendors that provide hardware authentication and other ‘highly dependent’ technology aspects of your infrastructure
• Loan staff brought onboard by HR and contractors

A progressive outsourcing / partnering has occurred with businesses where access to key networks are allowed, at least for a temporary basis.  In some cases the security design, management, log monitoring, and underlying software are all designed by third parties.  The cost of overseeing, testing, vetting, and validating the integrity / security of these operations must be considered at this time.

The scenario of India as a country conducting espionage created a timeline example, while humerous, is meant to provide a simple description of the current environment:

1. Businesses outsource IT operations to company
2. Team that managed operations hired by offensive security group
3. Same team leverages prior knowledge to attack and circumvent customers throughout region
4. Business does not have security through obscurity and in fact, is naked defensively against these individuals as most of security safeguards are the same
5. Business, in most cases, is not monitoring these partners for activities such as reconnaissance
6. Finally, the BPO and deep network (family and financially) of businesses where outsourcing occurs creates the possibility where approved access itself may be hijacked by attackers

Organizations must seek assurance regarding the operations of third parties, but also institute monitoring, detection, and response capabilities to ensure the ability to identify and limit these events.

Other thoughts / considerations?

James DeLuccia IV

 

When Cryptography is irrelevant, bypassing key card security

A malware executed attack was highlighted by ActivClient that provides technology for secure authentication (smart cards to comply with the GSC-IS 2.1).  The attack is described in detail in a number of sites, such as Security Week here, and I would encourage reading the explanation of the attack by AlienVault here.

What is interesting here and relevant to all security practitioners and sectors is that cryptography at some levels can be made irrelevant.  The immense sophistication of the crytography and hardware manufacturing placed within these keycards and their infrastructure, in this case, are countered simply by capturing the pin that is associated with the key.  That allows an attacker to access the protected resources the card was designed to restrict.  Specifically the attack works because the attacker gets the PIN through a key logger, then binds it to the local computers certificate, and finally attacks remote resources protected by key card whenever the card is connected.

In all, a pretty elegant way of defeating what would be a complex and low-return attack vector (hacking the crytography).

The takeaway is that, as always it seems, the old assumptions that hardware / cryptography / and standard processes are enough is wrong.  A practice of continually evaluating the impact of new attack types (variants) and the new ability of attacker.  Plus, the recent ongoing attack on the underlying security safeguards as a means of attacking an organization has reached a critical level.  In the past 12 months anti-virus source code has been stolen; 2 factor authentication tokens perceived as insecure due to the RSA breach; Certificate Authorities breached and poisoned, and this demonstration of bypassing card security.

The malware yes, could be detected through malware and behavioral IPS type technology on the network and host.  The increased activity / parallel queries of a user could yes be detected.  The vulnerabilities allowing the installation in this particular case could also be patched.  The result though is still an ongoing need to evolve security practices; monitor and respond rapidly to suspect activity, and reduce / limit access as much as possible.

Other thoughts and avenues?

Kind regards,

James DeLuccia IV