Tag Archives: Validation

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:
http://www.emc.com/microsites/rsa/security-for-business-innovation-council.htm

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

James DeLuccia IV

Advertisements

Elevating your Vendor / Supply Chain risk assessment

This past few weeks I have been working with a few clients and researchers on the vendor side / supply chain risk of business operations.  The common place activities of course exist, and include at least:

  1. Weighing the criticality of each vendor (to refer to supply chain too moving forward) to operational state of the business
  2. Weighing aspects of regulatory and contractual mandates of said vendor
  3. Weighing classic #infosec considerations – C.I.A. ++
  4. Establishing a tiered system of vendor management practices based upon data, system access, and of course points 1 & 2 above.
  5. Executing and evaluating these vendors through an actual evaluation of their operations (appropriate scope applied) to ensure that security and operational activities are in place for YOUR business dependent assets — this is key here: a powerpoint presentation is not satisfactory, period.  It does not matter who the vendor is – big, small, big brand, or otherwise…  the vendor assessment is not satisfied with this type of response, and should be considered a fail and raised to management to consider next steps.)
  6. Tight integration with legal, procurement, and risk management to ensure that (garbage in and garbage out) good vendors are added, and that actions can be taken balancing the strategic need of the business properly.
  7. Severe relationships with vendors that do not meet the requirements of your business

Now the above doesn’t mean establish a static assessment approach with a litany of questions pulled from the internet, but instead should be a thoughtful key set of controls that the vendor MUST address and maintain over the course of the relationship.

Generally, the above are quite standard and commonplace..  What recently has been interesting to me is (pardon the use of an industry phrase) the use of ‘out-of-band’ signals regarding vendor and supply chain risk.  I shared two of these thoughts online today on twitter:

  • How often does your risk assessment & vendor mgmt program factor in supply chain risk? Low hanging fruit: Monitor their breaches
  • Who follows the 10-k filings of key businesses that are suppliers and peers at the CSO / CRO / CISO level?  These are key inputs into where vendors are setting their priorities, and any red flags (infosec issues; operational concerns; financial challenges)

It is imperative today to KNOW what vendors (supply chain) participate in your organization, and extend the vendor program to bring these into consideration.

There are many other areas to consider, and I would love to hear others ideas .. here or @jdeluccia

Cheers,

James DeLuccia

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

 

PCI DSS 2.0, the update and you…

A tremendous amount of focus has been upon today when the PCI Council released publicly the latest standard for the payment card industry.  There undoubtedly will be an incredible amount of discussion on the varied points, and I will try to identify the most valuable over the next several days.  To that point, though I wanted to highlight a few nuances that enterprises must consider with regards to this new standard.  Most importantly, how the payment card industry is evolving.

The new standard, available for download today, has numerous points of clarification and expansion on security controls – all designed to secure the highly trade-able data.  Interesting highlights:

  • Further clarification that businesses cannot outsource their compliance to a third party, nor can a contract satisfy third party compliance agreements.  This has been very clearly stated for a long time within the Card Brands (Visa in particular) operating regulations, but is now stated absolutely in page 16 and again under requirement 12.8.  A nice post available here goes into greater detail.
  • The new standard focuses more on ensuring actual controls are effective and operational and less about simple paper verifications.  This is a change as it approaches the intent of the standard, and will provide better ability for organizations to protect their card holder data. (i.e., 12.9 ‘Be prepared to respond immediately to a system breach.”)
  • The usage of ‘All’ is more frequent in the new standard.  This covers areas of policy consideration and technical solutions.  Careful awareness of the scope of the payment environment will ensure lower risk, and greater ability to weave the PCI DSS 2.0 into enterprise security programs.
  • Greater updates also were focused on the Compensating Controls section, and should be carefully reviewed going forward.

Branden Williams’ always has valuable data points, and his article related to the new release can be found here.

More to come in the very near future, but in the meantime – read the standard yourself; consider your organization’s moving forward strategy; develop a comprehensive data security program that includes PCI controls and risk considerations, and of course consider the business objectives from all angles.

Best,

James DeLuccia

Do ISO entities need to be PCI DSS Compliant?

Who needs to be compliant with the Payment Card Industry Security Standards Council standards?  Well, the default response is usually – anyone who stores, process, and transmits card holder data.  There is constant discussion on pre-auth / post-auth / banking partners / etc..

A recent question I received was … Do ISO (Independent Sales Organizations) need to be compliant with PCI DSS?

This is a great question because it brings into the forefront the Third Party Providers.  While the classic response – “it depends” applies generically, let me elaborate and provide where it DOES exist.

According to Visa’s website, an ISO for this definition is also more broadly classified as a “Third Party Agent”.  Specifically here are the various functions that can be performed (This is key for eliminating the it depends statement from your situation):

A TPA can perform any or all of the functions of an: Independent Sales Organization (ISO), Third Party Servicer (TPS), Encryption Support Organization (ESO) and Merchant Servicer (MS). Each function performed by the TPA must be registered by each Visa client that is utilizing those services. TPA functions that require registration include but are not limited to:

  • Merchant or cardholder solicitation activities and / or customer service — these are performed by an ISO
  • Prepaid program solicitation activities and / or customer service — these are performed by an ISO
  • Loading or injecting encryption keys into ATMs, terminals or PIN pads — these are performed by an ESO
  • Loading software into an ATM or terminal — these are performed by an ESO
  • Storing, processing or transmitting Visa account numbers — these are performed by either a TPS or a MS
  • Deploying and / or servicing ATMs – these are performed by an ISO

Beyond registration requirements, all service providers – need to be compliant, as it is the acquiring banks liability if they are not.

Both issuers and acquirers must use, and are responsible for ensuring that their merchants use, service providers that are properly registered with Visa. Where applicable they must also ensure that all such entities are compliant with the PCI DSS and PCI PIN. Although there may not be a direct contractual relationship between merchant service providers and acquirers, Visa acquirers are responsible for any liability that may occur as a result of non-compliance.

In addition, Visa has provided enhanced clarification in their list of ISOs (published 7/15/2010) that lists registered organizations.  The document states that “entities utilizing this list should perform their own additional due diligence to ensure that the service prover is also compliant with any additional requirements that the entity may have in place.”… “Entities that store, process or transmit cardholder data must be registered with Visa and validate PCI DSS compliance.”

There are certainly relationships that may provide exceptions, but the process above shows that if you store, process, or transmit card holder data – proper security and compliance (and Validation where appropriate) with PCI DSS is necessary.

Thoughts?
James DeLuccia IV

PCI DSS Update 1/16/09: Discover Validation Levels

Discover has updated their validation requirements to be more explicit today.  The press release states:

DISC is Discover Network’s compliance management program and was designed to support the requirements outlined in the PCI DSS. The PCI DSS is an industry security requirement for safeguarding payment cardholder data. It was developed to facilitate the broad adoption of consistent data security measures on a global basis to assist in the prevention of cardholder data compromises in the card payments industry. PCI DSS compliance is required of any organization that stores, processes or transmits payment cardholder data.

Discover’s merchant level framework enhancement helps bring network merchant categorization into closer alignment and each merchant level will have its own associated validation and reporting requirements. The merchant level framework is comprised of four levels:

Level 1 – all merchants processing more than 6 million Discover Network transactions per year; any merchant that Discover Network determines should meet level 1 compliance and reporting requirements; all merchants required by another payments network to validate and report as a level 1 merchant
Level 2 – all merchants processing 1 million to 6 million Discover Network transactions per year; all merchants required by another payments network to report compliance as a level 2 merchant
Level 3 – all merchants processing 20,000 to 1 million Discover Network card-not-present only transactions per year; all merchants required by another payments network to report as a level 3 merchant
Level 4 – all other merchants.”

Check out the Discover Validation Requirements here

The site is dynamic javascript so no direct links, but if you select Merchant / Service Provider / Acquirer and choose the link highlighted in the screenshot below you will see the validation definitions and requirements:

picture-1

Overall a nice layout, in line with the other Card Brands, and a pleasent interface to research.

Kind Regards,

James DeLuccia IV