Tag Archives: PCI DSS

What do major developments in big data, cloud, mobile, and social media mean? A CISO perspective..

Screen Shot 2013-02-26 at 6.52.56 PM

Tuesday afternoon the CISO-T18 – Mega-Trends in Information Risk Management for 2013 and Beyond: CISO Views session as presented focused on the results of a survey sponsored by RSA (link below).  It provided a back drop for some good conversation, but more so it gave me a nice environment to elaborate on some personal observations and ideas.  The first tweet I sent, hammered the main slide:

“Major developments with Big Data, Cloud, Mobile, and Social media” – the context and reality here is cavernous.. “

My analysis and near-random break down of this tweet are as follows with quotes pulled from the panel.

First off – be aware that these key phrases / buzz words mean different things to different departments and from each level (strategic executives through tactical teams). Big Data analytics may not be a backend operational pursuit, but a revenue generating front end activity (such as executed by WalMart). These different instantiations are likely happening at different levels with varied visibility across the organization.

Owning” the IT infrastructure is not a control to prevent the different groups from launching to these other ‘Major developments’.

The cost effectiveness of the platforms designed to serve businesses (i.e., Heroku, Puppet Labs, AWS, etc…) is what is defining the new cost structure. CIO and CISO must

>The cloud is not cheaper if it does have any controls. This creates a risk of the data being lost due to “no controls” – highlighted by Melanie from the panel.  <– I don’t believe this statement is generally true and generally FUD.

Specifically – There is a service level expectation by cloud service providers to compensate for the lack of audit ability those “controls”. There are motions to provide a level of assurance to these cloud providers beyond the ancient method established through ‘right to audit‘.

A method of approaching these challenging trends, specifically Big Data, below as highlighted by one of the CISO (apologies missed his name) w/ my additions:

  • Data flow mapping is a key to providing efficient and positive ‘build it’ product development. It helps understand what matters (to support and have it operational), but also see if anything is breaking as a result.
  • Breaking = violating a contract, breaking a compliance requirement, or negatively effecting other systems and user requirements.

Getting things Done – the CISO 

Two observations impacting the CISO and information technology organization include:

  1. The Board is starting to become aware and seeking to see how information security is woven within ERM
  2. Budgets are not getting bigger, and likely shrinking due to expectations of productivity gains / efficiency / cloud / etc…

Rationalization on direction, controls, security responses, must be be fast for making decisions and executing…

Your ability to get things done has little do with YOU doing things, but getting others to do things. Enabling, partnering, and teaming is what makes the business move. CIO and CISO must create positive build-it inertia.

Support and partner with the “middle management” the API of the business if you will.

  • We to often focus on “getting to the board” and deploying / securing the “end points” .. Those end points are the USERS and between them and the Board are your API to achieving your personal objectives.

Vendor Management vs procurement of yester-year

Acquiring the technology and services must be done through a renewed and redeveloped vendor management program. The current procurement team’s competencies are inadequate and lacking the toolsets to ensure these providers are meeting the existing threats. To be a risk adaptive organization you must tackle these vendors with renewed. Buying the cheapest parts and service today does not mean what it meant 10 years ago. Today the copied Cisco router alternative that was reverse engineered lacks an impressive amount of problems immediately after acquisition. Buying is easy – it is the operational continuance that is difficult. This is highlighted by the 10,000+ vulnerabilities that exist with networked devices that will never be updated within corporations that must have their risks mitigated, at a very high and constant cost.

Panel referenced the following report:

Thank you to the panel for helping create a space to think and seek answers, or at least more questions!

James DeLuccia IV

Passwords are Dead, Part II 2nd False Premise – a collaborative research effort, being presented at RSA 2013

The advent of user created, managed and handled passwords as the sole means of authenticating is coming to an end. The utility of these was defined in an era based on assumptions of brute force capability, system computing power and pro-active security teams.   – After much debate and analysis … there is the thesis

Screen Shot 2013-02-12 at 9.58.14 AM

This is Part II of the topic being explored and discussed at my Wednesday session at the RSA Conference in San Francisco (2013).  To see the first thesis and False Premise 1, please see the original post.  Jumping right in – looking forward to more feedback (thanks for a generous emails, but don’t be shy at the comment field below)!


FALSE PREMISE TWO: Password strength should transcend devices – mobile, tablets (iPad, surface) [Updated 2/12/2013]

MOBILE devices:
What is the intent of the password? To stop high CPU encryption cracking systems .. or prevent inadvertent strangers from accessing the data?  Today we wrap in mobile (BYOD type if that suits you) systems into the corporate password requirement sphere, and in some cases are being more creative than other platforms.

For instance, it is recommended on a popular Apple iOS device site to use “accent characters for creating a super strong password“. Agreed these are more difficult to guess, but is that the threat we are seeking to mitigate?  In the space of X character spaces how creative must we get?

What are the risks to these mobile devices:

  • Theft
  • Data leakage violating regulatory, contractual, or privacy expectations of customers

If we consider the two threats – Theft is not mitigated by the password, as the device will simply be wiped.

[Updated 2/09/13] Data leakage is only possible if the device is ON and the password guessed before it locks itself permanently.  A feature readily available and easily implemented by the end-user, even more robust with corporate implementation technologies.

  • So in this case, the password only needs to not be one of the top 10 most common phone passwords.  At that point the device locks and can self wipe.
  • Another scenario is that the password was gleaned through recording / shoulder surfing / or simply left unlocked.  Each case the password strength was not an issue.  Other situations?

As we move into an ever mobile, data everywhere, and always connected scenario an interesting ecosystem of access & authentication appears, that requires continued serious challenge against the assumptions of our security and assurance programs.

Diving in …

Data is mobile – what role does a single password play in accessing sensitive data? Data stored on device (Cloud storage we can address on the integration point below) is at risk to a number of threats:

  • The device can be attacked directly (similar to any other computing device with IP addresses and Ports) wirelessly, but typically requires physical proximity (simplest) which is reserved for either random or very targeted attackers.
  • The device can be stolen, and if no OS passwords, than the Data itself is attacked/accessed directly. An unlocked device introduces risk mitigation techniques that are harder, so password is EASIEST. A password on the data within an application is a worthless without some form of self-destruct functionality similar to that of the OS level safeguards.

>> Why are passwords WORTHLESS at the application level in this situation?

>>> If the attacker is ON the device (physically or remotely) and our Use Case is an encrypted database – the attacker can copy that encrypted database to their system for local attacking (easy and zero user awareness), or they can access the database locally via brute force until they get in.

The data is at risk regardless without some form of self-destruct and tremendous levels of assurance related to the encryption of the data(base) itself.

  • Other thoughts here?
  • What is missing?

Passwords plays a significant role at certain tollgates upon the data (when stored on the device), and less the more “access” the attacker gets to the underlying system. A common refrain of attackers is – with “physical” access I can break into anything. We must today deal with ALL ACCESS is PHYSICAL when the data is mobile.

Plethora of devices – Today data is accessed from many devices, some owned by corporations, by end-users, or nobody – kiosks. Single passwords entered into systems allowing single thread authentication where NO assurance is understood of the underlying system and no situational awareness of the User presence seeking authentication results in failed security.

  • The reuse of passwords across devices threatens the confidentiality of the password itself (as much as that matters).
  • The multitude of devices increases the need to redefine what is “access” and the functions of authorization (I used “functions” instead of “rules” intentionally to draw attention on the necessity for a broader approach to solving this constraint)

Integration with third party service providers – [to be expanded…]


Conclusion – a preview:

  1. Stationarity, is defined as a quality of a process in which the statistical parameters (mean and standard deviation) of the process do not change with time.” – Challis and Kitney November 1991
  2. Offline Data level authentication – Offline in an ‘always connected’ world

[Disclaimer: First off this is my research and not anyone else’s. Second, the examples above are meant to illustrate technical realities in a reasonably understood presentation. Lets focus on the problem .. identify weaknesses in the argument; and introduce the mitigation so greatly required in our online world.

I share and seek these answers for the preservation and enhancement for our way of life… as simple as that and I appreciate you being a part of my journey]

Always seek, everything…

James DeLuccia

Twitter: @jdeluccia

Who will be the Jamaica Ginger of Information Security?

I read a short section in Bruce Schneier’s book Liars and Outliers that tells the tale of Jamaica Ginger:

“an epidemic of paralysis occurred as a result of Jamaica Ginger… it was laced with a nerve poison… and the company was vilified”, but not until 10s of thousands were victims, this resulted in the creation of the FDA.

To date, throughout most industries there is no absolute requirement with meaningful incentives to introduce and sustain operational information technology safeguards. There are isolated elements focused on particular threats and fraud (such as, PCI for the credit card industry, CIP for the Energy sector, etc…). So what will result in the Jamaica Ginger of information security?

Some portend that a cyber-war (a real one) that creates such societal disruption; a long enough sustained negative impact to survive the policy development process, and driven enough motivation to be complete. OSHA, FDA, and other such entities exist as a result of such events.

The best action enterprises can follow is to mature and engage sufficient operations that address their information technology concerns in the marketplace. As a means of self preservation; selfish (perhaps) demonstration of a need to NOT have legislation or a body established (such as the Federal Security Bureau), and ultimately preparedness should such a requirement be introduced the changes to your business would be incremental at best.

Other thoughts?

James DeLuccia

Connected Systems of PCI – Identifying; Securing; Attesting

The payment card industry standard articulates very prescriptively what should be done for all system components that are within the payment card process.  An area of usual confusion is the depth of abstraction that should be applied to the “connected system” element of the standard.  Specifically, the standard states the following:

The PCI DSS security requirements apply to all system components. In the context of PCI DSS, “system components” are defined as any network component, server, or application that is included in or connected to the cardholder data environment. ―”System components” also include any virtualization components such as virtual machines, virtual switches/routers, virtual appliances, virtual applications/desktops, and hypervisors. The cardholder data environment is comprised of people, processes and technology that store, process or transmit cardholder data or sensitive authentication data. Network components include but are not limited to firewalls, switches, routers, wireless access points, network appliances, and other security appliances. Server types include, but are not limited to the following: web, application, database, authentication, mail, proxy, network time protocol (NTP), and domain name server (DNS). Applications include all purchased and custom applications, including internal and external (for example, Internet) applications.

– PCI DSS 2.0 page 10

To simplify – there are the system components that are involved with the payment card process, and then there are the supporting systems (connected systems) that also are in scope of PCI DSS.  An example would be the patch server where the in-scope PCI system is receiving patches (but there are dozens).

So a rule of thumb on scope most offered in the industry is:

If you can digitally communicate with the system it is a connected system (this includes UDP, TCP, etc …) it is in scope.  

A nice write up by Jeff Lowder referring to specifically the security system components can be found here written in 2010.

A Korzybski abstraction problem:

How many levels of abstraction should one undertake?  Meaning – should that same patch server then be examined to see what systems are connecting to it and thus also be included in the ‘connected system’ web?

The answer here is generally no – the abstraction is only one level deep.  That doesn’t mean best practice risk and security practices evaporate, so no leaving that server unpatched on the internet or anything.

What Requirements of PCI DSS should be applied to these ‘connected systems’?

The standard makes it clear in the beginning “The PCI DSS security requirements apply to all…”  So, every PCI control applies to the connected system under discussion and identified through the abstraction of the services supporting the CHD environment itself.  Limitations can be applied to the core system components that make up this “connected system”.  Such as in the virtualization space, the hypervisor risks and controls are differentially applied from the entire standard.  These exceptions from fully applying the PCI standard directly to the connected system must be limited and done with clear awareness.  [Updated: All requirements should be considered … each QSA is different but addressing the risk with an eye towards compliance is the best and safest bet.  Shopping for someone to accept a state of controls is a painful road]

An “Open PCI DSS Scoping Toolkit“(pdf)  published on August 24, 2012 is available that provides an excellent structure in methodically determining scope and the controls that would be applicable.  While not a product of the PCI SSC or a technical group – there is good content here that should be carefully considered as part of every security and compliance strategy.  Thanks to Eric Brothers for the note! [Updated 12/5/2012]

Another good write up is offered here where a good articulation on the two factor authentication exception; file integrity monitoring exception, and a few other practices are nicely elaborated by Andrew Plato (Plus check out the comment threads.. very informative though proceed with caution as this is one QSA interpretation).  Definitely worth a review, though sadly after a review there appears no other elaborations within the PCI SSC on this topic.

This write-up is an exploratory effort to seek clarity by consolidating thoughts of leading individuals in the payment card space and client environment realities.  Any additional insights or perspectives you have are welcomed and requested in the comments below!  I’ll update as anything is shared.


James DeLuccia

How to improve the maturity of your security program – Learn from mistakes made others!

Organizations struggle with a complex information security compliance program needs placed upon the organization.  Mature organizations participate in regular self review and improvement activities on an annual basis, and in some organizations as regular as monthly.  These organizations are fortunate to have larger security teams that reflect the global (think Fortune 500) deployment of assets.  This network provides an immensely valuable feedback loop on the following, among many others:

  • What are effective practices
  • What policies are great for the business, and where are exceptions being raised frequently that may indicate unknown business requirements
  • Attack patterns and weaknesses in the security program based on statistical review of events within the business
  • Where are programs meeting customer / client requirements – based on sales attributions and audit findings, respectively.

For organizations of this sophistication and those of all other sizes there is an additional input that raises the overall efficiency and effectiveness of the security compliance program.  That is through a self comparison against public data.  Specifically data released by government audits, intelligence committee reports, and guidances / complaints issued by government enforcement agencies.  These are immensely helpful in providing businesses across all sectors insights into security threats, trends, shifting perceptions of “due care”, and areas where risks are ebbing and flowing.

A simple set that an organization may consider includes:

The takeaway here is that every organization should regularly identify these sources, consolidate them in a manner that can be analyzed, and develop an intelligence report on any gaps in practice and security controls as documented by these organizations.  These apply to every organization and not simply those in the government space.  The process of careful analysis against the organization’s strategy combined with the rote knowledge of the practitioners internally can support realizing these benefits.

The genesis of this article was inspired through close workings with Fortune 50 organizations and developing leading global security programs.  A nice article illuminating this and other opportunities for improvements to security compliance programs is by Adam Shostack, in “The evolution of information security“.  A very good read.

Thoughts .. and expansions of idea are always welcome!

James DeLuccia IV


Managing information Security in an ever changing environment

Can a network be defended and secured?  Of course, observe the red team / blue team activities that are executed by businesses, governments, and at conferences.  There is one catch, these do not reflect reality.  Businesses are living networks and under constant change either directly encouraged or indirectly effected by the windows of the market and universe as a whole.

A fine quote that brought this to bear for me was published in an NSA publication stating: “One simply must realize that while the search for the right foundations proceeds, construction will continue.” where the article describes how the Duomo in Florence was built without an understanding of how to build the planned dome at the top.  That is akin to information security today – the challenge and task of information security is to build and execute a security program that reflects that the business is in constant development, and we will not always “know” what is effective for where we are going.  Think Mobile and Cloud security as the current sources of concern and challenge.

The takeaway is to recognize that the standards organizations build their security programs upon (ISO 27001, NIST) and are regulated / audited against (PCI DSS, NERC/FERC) are in themselves in a constant state of change.  This is only matched by the dynamics of the changing foundations of what information security is protecting (mobile, cloud, etc..) and the market demands placed on the organization.  Being still is not the answer, but instead iterating rapidly with a conscious focus on the strategy of the organization with an enabling security program will enhance the longevity of the organization and the relative effectiveness of the security compliance program itself.

NSA Article referenced:  “Cybersecurity: From engineering to science” by Carl Landwehr

Other thoughts?

James DeLuccia IV

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.


James DeLuccia