Tag Archives: 2012

Synergy and specificity, a review of Forrester’s Simplify Cybersecurity w/ PCI

The recently published, Simplify Cybersecurity With PCI, by Heidi Shey and John Kindervag is an interesting and valuable read.  The premise is that the government regulations (any really) are generally obtuse and ideal focused without prescriptive how-to descriptions.  While the payment card industry standard (PCI DSS v2.0 in this case) is direct on what and how technology controls should be deployed.  The authors present a synergy that exists that can help an organization establish a security program.

I would definitely recommend businesses struggling to establish a security program to review the concept.  I would challenge those involved in establishing security programs and enhancing such programs to focus on their core business strategies and focus on an iterative cycle, and not simply a controls exercise.  Ultimately I agree there are synergies as described by the authors, and I feel the mappings is quite insightful, but I would pair this with the cyclical nature of an ISMS to round out the edges and make it a more pragmatic and ultimately effective program.

One note also, is that the authors intend that the PCI DSS standard is appropriate for mapping, but I would caution readers and all who utilize PCI DSS.  The standard is specifically articulated for a set of risks and typically bounded by scope of the card data environment.  When utilizing these standards it is important to eliminate and or address these pre conditional weaknesses first, prior to establishing a proper security, and ultimately compliance program.

Other thoughts?  I have personally done many mappings (most recent 134 global regulations and guidances) and can appreciate the value of such alignments, but also with each standard carries assumptions that must be managed at the program level.

Best,

James DeLuccia

Having a ROC does not make an organization secure or compliant – a view into the risks of PCI and periphery events

Why should an organization address and comply at least with industry supported practices?  A question of compliance versus driving business value, and one often raised in the Payment Card space is important to understand and convey at every level of an organization.  The importance is building an organization’s security and compliance program in a manner that cohesively manages the demands of client requirements, government cares, and general competitiveness.  In an era where competitiveness includes thwarting attackers focused on poisoning your supply chains with misinformation or directly seeking to “acquire” the Intellectual Property that makes the business competitive.  The executive and board of directors within an organization are acutely seeking demonstration of focus and effectiveness.

So what are the risks to an organization not managing the risks of an industry standard?

To answer that below I will speak directly to PCI (to eliminate the obnoxious “it depends” statements) and about a Fortune 500 company that has other intellectual property.

Ultimate risk to an organization out of compliance with PCI is well documented (on the Card Brand sites themselves and breach news sites), but stems from a violation of contractual agreements with the business’ banks and ultimately the card brands.  This contractual obligation (and violation) can be determined without a breach.  The violation (profiled in a public court case out West) can be identified when a QSA / Forensics team from the Card Brands / or any of their team members conduct an assessment of compliance to the organization.  The court case referenced is of a restaurant that had been suspected of a Common Point of Fraud; proven to not have been breached, but in violation of PCI DSS based on forensics report issued to Bank & Card Brands).  So, the risk and associated damages can result from a breach (classic) or simply by confirmation that the business violated the contract established with the Card Brands.

The highlight here is being compliant means addressing the threat vectors to the business and the assets requiring protection.  Failure to achieve those results from either path can result in a number of business and financial negative events.  These, in part, are described below:

  • Financial punitive fines by the Card Brands ($500k is a number published by the Card Brands)
  • Per account # breached associated costs & fines – this number is a hard figure to lock down .. $100-$170 per card in some cases
  • Higher interchange fees per card transaction for the entire legal entity – this is very costly and most damaging
  • FTC and public government actions, that may include recurring privacy audits (such as 20 years of third party audits)
  • Automatic level 1 status for the company (which requires annual onsite attestation)
  • If you look at TJX and the other public breaches they have published hose expenses around $130M+
  • Civil / class action lawsuits likely

There are also reputation and periphery risks to the business:

  • The company possesses additional data protected and considered sensitive by industry and governments around the world, PCI Data is one element but it is likely that these systems share networks, applications, and permissions.  The breach of one could inadvertently result in the breach of the other (PII)
  • Not at least complying / deploying operational security controls broadly considered baseline practice would be damaging in an era when security of data and confidence is so important

The highlight here is that the risk is not addressed by the issuance of a ROC by a QSA or having run assessments, but that the security and risk programs are operational and effective.  These ROC and assessments are simply attestations of a program that is mature and functioning.  Compliance is not deemed by a ROC nor does it provide safe-harbor in the common sense of the term.  A long standing statement by the PCI SSC is that “no compliant organization has had a breach” <– including TJX, Heartland Payments, and Global Payments all breached with current ROCs signed by TrustWave.

The success of the PCI program is the ultimate reduction of risk and adequate security controls of the organization.  The risks addressed through a cohesive integration with the operational elements of the business are the critical success factors.

Other thoughts?

James DeLuccia IV

Compliance mandates do not make up your enterprise security program (PCI, SOX, GLBA, etc.. included)

A challenge for large businesses is addressing their own information security needs to manage their operations in a manner that allows them to be resilient and adaptable in an ever competitive market place.  Each organization is different – the risks and the needs to mitigate.  A painful evolution of the past decade has been the mistaken direction organizations have taken to build / address singular compliance instances.  Meaning, organizations develop programs to address single compliance requirements – vendors, SEC, industry, etc …  Not that these are not important, but a natural effect of this is the perception that the security “controls” (even the word doesn’t lend itself in the right non-audit light) are there to achieve compliance.

The mistake is achieving compliance to compliance requirements alone.  There is a gap in the business’ OWN needs.  Over the past year I have spoken on this topic publicly at conferences and my book  has a huge focus on aligning and establishing business requirements cohesively.

To elaborate on the graphic … the CxO office must be aware and share their strategy – typically easy to find, as I generally begin building these programs from the 10-k reports over last two years.  These feed the information security program elements and form the decision framework against all technology, security controls, risk frameworks, sourcing considerations, recovery timelines, etc…  In addition, the compliance elements must be addressed – but with the understanding these are risk transfer activities by third parties.  Not to be the basis of the enterprise program, but a singular consideration.

The capability of the organization to address market competitive requirements is based upon the proper balance.  Here you can see the target is 85% of the program is made up by the business’ own innovative and market driving / supporting activities.  15% of the program to meeting these ‘license to operate’.

The takeaway is to challenge your organization’s singular managed compliance initiatives and a deep dive on budget alignment to business revenue generation.  There must be rationalization to the safeguards to make the business efficient and effective – that includes safeguarding and enabling the business to conduct business, everywhere.

Thoughts?  Challenges?

James

Android fragmented device market = high risk mobile platform

The market of mobile devices is experiencing faster growth than the PC, and with that growth comes user adoption, the need to enable systems to interoperate, and of course keep the data flowing. The challenge on mobile devices crosses many spectrums, but one area to highlight deals with the variety of “branches” of the Android operating system and device platforms.

A nice visual was put together over at OpenSignalMaps that shows the variant of devices running the Android OS based on their application collected data. This is by no means a complete list, but it effectively defines the problem space. There are a lot of platforms that can run Android, have apps installed, and each can be utilized by the consumer. This trend will only radically increase as more and more devices are enabled through Android licenses (TVs, cars, toasters, space ships, etc…).  The latest iterations from Amazon are a great demonstration of custom hardware, blended operating system components, and user linked service providers to application and device.

A quick bit of details on their findings – total distinct devices 3,997!  Though 1,363 were only seen once – may result of data source and one-hit wonders.  Still that is a very large population.  The device model breakdown is the top graphic .. the authors provided a number of different slices of the data, and it is worth reviewing.

As for an information security and compliance perspective, below are two key areas – software updates & chipsets:

  • Software updates … not timely, consistent, or completely absent depending on the platform.  This relates to the Apps compatibility with the platform and OS.  The operating system itself as highlighted on Google’s own dashboard shows a broader active OS base across legacy operating systems than Apple.  The lack of software updates – being applied; existing, and being compatible must be mitigated.  The problem must be framed here properly – Updates in the “new” mobile world are not always to patch security vulnerabilities.  Some, many, make feature updates that are user focused / backend improvements, etc…  Therefore some updates (read; SOME) are not necessary but are nice to haves.  The business needs to integrate these considerations within the broader IT framework management structure to ensure that risks are mitigated that exist.  Sometimes updating to the latest version (to get rid of that nasty little red number) is not the right course of action.
  • Hardware chipsets… not to be trusted.  The hardware that makes up these tablets is based on a global supply chain.  As organizations move beyond single vendor sourcing (ahh, the good ol’ days of Blackberry – yes I said it), to multi vendor / platform, awareness of the hardware becomes important.  Hardware is specifically a risk to be addressed when the focus is on High Value Assets and Persons.  Meaning those who have access to that type of data or are likely targets of attacks.  It it those persons you would manage the device platform selection upon.  The number of poisoned chipsets coming out of China and other areas is increasing.  An appropriate level of consideration is important.  Beyond poisoned chipsets (i.e., malware / trojans built in), some chipsets have flawed designs that are identified by researchers (and published such as at DefCon), and always utilized by attackers in the wild.

There are other areas of consideration, but the two above draw on the 80/20 rule… would love other thoughts here!

Google also has a developer dashboard that highlights information about the deployed operating system distribution and adoption (as recorded based on connection to Google’s Play) that is worth visiting.

To sum it up …Having worked with clients to understand, frame, and execute plans that embrace mobile technology across their business requires an understanding of what is the opportunity space. Each enterprise is a bit different as a result of industry, age of company, and of course their business objectives. The challenge of a fragmented (Android) market space is that it creates risks that need to be viewed across a spectrum within the organization. The fragmentation is not obvious (not 1,000+ iterations!) and so the field of risk is not within line of site.  Organizations tend to go through phases when adopting mobile technology (consumerization) – block; deny; resist; deny without blocking; and finally yield…  Given the fragmentation mature businesses move beyond simple prohibition, but instead initiate a process to put in place information security safeguards to mitigate the risk to an effective level.

The authors of the original study made a good point at the end – the blessing and curse of Android is the fragmentation and not knowing where the application will run and on what hardware (country, etc…).  Finding an operational balance is the key.

Thoughts?

James DeLuccia

Security and Privacy risks from Facebook Apps

The trust and complexity of such relationships between key Apps, users, and our data is a challenge for individuals and businesses.  A recent study was done of 500,000 FaceBook Apps (bear in mind this is ONE platform for Apps dedicated to it, so extrapolation and assumptions are needed, cautiously, for other platforms), and found interesting facts.

The study was done by Secure.me who sells reputation services, so a grain of salt needs to be taken, but as the research shows (even with a grain of salt) there are enough considerations to impact most information security, compliance programs, and risk treatment plans.

A snippet of the findings include:

  • About six out of ten of the apps (63%) can post on to timeline (honestly, do you even know what others in the platform are seeing regarding your own data/timeline/posts/and associations?)
  • More than two thirds of the apps (69%) know stored email address
  • Nearly every third app (30%) knows the account’s birthday
  • 5 out of 100 apps (5%) access your photos and videos, going beyond the profile picture
  • Every tenth app (10%) is informed about hobbies and interests
  • 10% of the apps have access to your geo information including check-ins, hometown or current city
  • 1 out of 5 apps (21%) can access personal data of your “friends” including friends’ birthdays, education and work history

Check out their post here on the details.

The action here for businesses is to review their social media strategy as it is integrated within the enterprise security & risk programs and the privacy elements of the business.  Note, the social media considerations listed above are partial inputs into this broader program that considers such risks.  It would be nice to have dedicated teams for each type of program (social media, cloud, etc…), but in most mature organizations the framework and practices exist and simply should be augmented.  This study is a nice input providing awareness to singular risks.

I have been doing research on this very problem within the smartphone app space.  To identify similar trust threats and privacy concerns.  Much to be done…if others know of existing research, kindly share!

Best,

James DeLuccia IV

NSA chief endorses the cloud for classified military cyber program, considerations

Perhaps old news given the NSA chief made the below comments in 2011 presenting to Congress asking for support of the projects (basically a budget justification meeting).  What is interesting is how he frames the current state weaknesses versus the benefits of the future state of leveraging Cloud architectures.  He is also referring to several key programs that are deployed and seeing active participation.

As this relates to information security professionals, control safeguards, and ultimately PCI DSS is for the eye of the beholder.  A striking point is to fundamentally challenge your risk assumptions and the benefits of moving to the cloud.  A key consideration here is the concept of redeploying, rearchitecting, and I would say restart managing access and security anew.  Cloud provides an inflection point to businesses, and governments to start fresh to meet the current threats.

As I have often have CxO discussions, the framing of these technology changes provides a mechanism to reach a stability and integrity of technology supported operations (hard to find one that is not).  Consider the NSA Chief points below and perhaps consider that he is speaking of highly sensitive data that has human life risks directly associated.  That type of data is highest sensitivity, and if such can be secured in a collaborative, cloud, integrated, and mobile enabled environment – why not other data elements and industries.

This is in line with the OCR NIST HIPAA guidance and recent clarification (June 2012) regarding how Cloud environments are subject to the BA agreement and security elements.  Clouds are permitted, but the expected controls must exist along with the proper risk management factors.

NSA Chief: “The idea is to reduce vulnerabilities inherent in the current architecture and to exploit the advantages of cloud computing and thin-client networks, moving the programs and the data that users need away from the thousands of desktops we now use — each of which has to be individually secured for just one of our three major architectures — up to a centralized configuration that will give us wider availability of applications and data combined with tighter control over accesses and vulnerabilities and more timely mitigation of the latter,” he testified before a House subcommittee in March 2011.

via NSA chief endorses the cloud for classified military cyber program – Cybersecurity – Nextgov.com.

Kind regards,

James DeLuccia IV

Download iCloud backups without the device, risk considerations

The ability to save data, sync information, and manipulate information online is extremely convenient and productive.  The risks that exist with this activity are fresh and emerging.  Unlike the physical-world risks that are impacted by kinetic attacks; weather impacts, and human events where the current state remains stable (i.e., the building doesn’t move addresses dynamically over night) the online Cloud-mobile device ecosystem does not.

This lack of state is an aspect that is both a feature that serves and cuts the enterprise.  The ability to provide updates without patches to the user is a key feature to cloud-mobile providers, and something in fact expected now of the end-users.   The virtual elimination of patching is upon us.

To highlight but a few alternate challenges that must be considered:

  • Configuration management – the onboarding of new applications and systems into an enterprise is done in a manner that ensures the system components themselves comply with the enterprise policy and industry operating standards.  This is challenged and new triggers and actions are required for cloud-mobile systems, as these may have new features (i.e., file transfer) automatically available to all users over night
  • Access and authorization – as the title implies (though such attacks are not limited to that of Apple) the technology deployed may permit alternative data access methods.  In the cloud-mobile ecosystem there is a presumption by the user that there is a physical link between the device (iphone / tablet) and possession implies such control / protection.  This is a fallacy of cloud-mobile, as possession of the device is not the key but instead the credentials associated to the stored repository of data.  Therefore the safeguards and information governance programs must focus on these assets (the credentials).
  • Geo-Location – Knowing where the data is processed & stored is critical, but not to a severity of knowing a zipcode.  Precise locations being shared introduce a security risk in general and do not serve the risk mitigation process.  Instead, gaining confirmation on regions of operation (i.e., so that weather can be considered in BCP), and the number of in parallel instances that will be running are important additions to consider with regard to these facilities.

So, as the “attack / forensic method” described in the title … one can w/ the authentication credentials of the user connect to iCloud and download a user’s total backup.  This may include contacts, documents, etc…  The tool is described here.

Again the point here is to begin considering operational and information security risk at the governance and sustainment level with respect to these mobile-cloud ecosystems.  Not focus on the single symptom of operating in this environment (having data d/led from iCloud).

Other thoughts?

James DeLuccia

/cp ITCC