One of my favorite parts of penetration testing is and always has been social engineering. I love it. In fact, I love it so much; I developed a real passion for it. My passion led well beyond the traditional social engineering and evolved into the study and practice of more sophisticated techniques associated with socio-psycho manipulation. It is a gift of sorts and who am I to question a gift? When speaking with prospective or current clients with respect to security assessments I have often implored them to include both physical security analysis and social engineering. This habit was formed upon entry into the world of professional security consulting where I sharpened these skills under the tutelage of many senior to me in both age and experience. Almost all of my earliest mentors in this space were or had been active in the United States DoD or like intelligence services, most of whom shared a common pedigree not unlike my own hailing from the world of information security and intelligence. These environments taught us to remain vigilant and open to idea that the unexpected should be expected therefore our ability to address anomalous events must remain categorically strong.
Over the years, within many engagements, activities of this nature were written into SoWs (Statements of Work for the lay person), and acted upon with full approval of parties both able to authorize such activity within and against their organizations and their legal representation (a detail I cannot stress enough that should not be overlooked). We would engage reconnaissance carefully leveraging skills we had cultivated in our former lives and applying them to the commercial world. We would engage in deep open source intelligence gathering and analysis in order to supplement our knowledge base regarding our target(s). We would become familiar with the physical environment in which our targets could and would likely be found. These locations would range from their places of business, to local restaurants and pubs, to local shopping districts to other geographic locales that we knew to be frequented by parties belonging to the organization, our target, in question. All the while we would be looking for ingress and egress points in addition to ideal areas for initial contact and exploitation. We would additionally identified areas in which useful information may or not be discarded by our targets that truly believed that no one would be interested (ah how I loved dumpster diving in my youth!). Finally, upon having enough information we would begin our careful insertion and infiltration. There is an art to doing this as much as there is a science and at times, the art becomes (or at least in my experience became), much more valuable.
These exercises almost always proved fruitful, as they would typically be multi-faceted involving multiple small teams each of which was cognizant of the others activities but all tasked with different missions during these exercises within the greater assessment. Some teams focused more upon the physical compromise of the environment, the acquisition of credentials and knowledge which could be socially engineered or stolen and thus counterfeited to serve our purposes in pushing deeper into the environment escalating our mission per our SoW and charter. Others would work on compromising individuals, seeking to gain their trust and subsequently their knowledge and any information considered noteworthy. Others still work on electronic and social engineering utilizing e-mail, web and telephonic techniques all designed to gain the trust of our targets or members of our target organizations in the hopes of escalating our privileges and advancing our efforts. This was good work. It was important work. And it was work that not all are capable of nor designed for. To the layperson reading this post I imagine it sounds outrageous if not frightening that work of this nature goes on and is conducted by security professionals in an effort to test and assess the security posture of a client and to a degree I can understand that attitude. However, this work is terribly important and often demonstrates weaknesses not previously accounted for within enterprise environments (public or private), during traditional security assessments and audits.
At this point you may be wondering whether or not there is merit in engaging a qualified team to do provide this type of service in addition to traditional services brought to the table as part of a security assessment. My personal perspective is that if you have overt responsible for the risk posture of an organization and understand that security or the state of being secure is contingent upon the three legs of the security stool (people, process and technology) being dutifully tested and exercised you most assuredly should do so. Failure to do so can expose you and your organization to a world of risk, which complying mindlessly with a three lettered data security standard or a mutagenic health-privacy act cannot hope to save you from. So what are we to do? First, if you haven’t already done so, conduct a meticulous review and analysis of your organizational information and physical security policies. If you don’t have any now is the time to remedy this deficiency. Should you (as I imagine most do, but will refrain from assuming), have these policies on hand review while employing a healthy dose of third party ego; remove yourself from the immediate, intimate involvement with them as they relate to your job and evaluate them as though you were brought in to do so as a third party. Do they look mature? Are they clearly articulated and well defined? Are they comprehensive? Do they address the natural bridges that occur between physical and logical security? Provided you have the resources, engage them to conduct preliminary assessments (provided they are qualified to do so), and if they are found to be lacking in the ability, do not hesitate to contact professionals with the appropriate pedigree, background and reputation to speak to about scoping a statement of work on your behalf. Remember that not every attack of a truly serious nature takes place across a wire and that many begin and end with a simple telephone call, a conversation around a smoking area or via a new hire.
Determinism vs Randomness: The Net Effect Upon Security
By nature, I am an empiricist; it is who I am and works for me based on my bent toward analytics and multi-faceted (at times onerous), levels of thought and pontification. I am unapologetic about the way I approach things; it is simply who I am. Having said that, I recognize that I am not – nor is my way of approaching things, universally embraced or right for everyone. To assert otherwise would be intellectually dishonest. I am particularly intrigued (and spend a lot of time reading and studying), determinism and randomness theory and philosophy. For many of us, life is as simple as asking a question which the quintessential Canadian thinking mans band Rush asked on its 1991 album Roll The Bones “why are here, because we’re here, roll the bones”; while for others the question of why and perhaps more importantly the answer is not so simple. I fall into the latter camp.
I a student of empiricism; I am a stalwart advocate of critical thinking and reasoning especially when it deals with philosophical schools of thought such as determinism vs. randomness and how they interact within the world in which I professionally live and work. These ideas are not new. In fact they are quite old. They are in many respects extremely old and as a result of their vintage, they have been and remain the subject of great debate. Authors and thinkers such as Nassim Nicholas Taleb, who wrote two of my favorite books on the subject : Fooled by Randomness and The Black Swan: The Impact of the Highly Improbable, go to great lengths to explain these concepts along with their impact on causality. So too did David Hume, the famed Scottish philosopher, along with Karl Popper and Colin Howson. Needless to say there is a long and strong tradition in examining deterministic vs. random philosophy as it relates to probability. The concepts are as old as time itself; as long as mankind has had the ability to reason he has struggled with whether or not events occur due to deterministic causes (or more appropriately because of events which exist and influence other events thus arriving at the cause for a current event), or due to sheer randomness. We are no different than our predecessor in this respect. We seek knowledge with respect to the origins of things and events in addition to what there existence will mean to us as we move forward. This desire to know unequivocally what influences outcomes and the probability of those outcomes is central to the theme of our existence. As a result, it infiltrates (if we are paying attention), all aspects of our lies from the most complex to the least. We find ourselves asking why certain things occur at the time and place that they did, and to what end. I happened to be in New York City last weekend making my way to LaGuardia Airport via the Holland Tunnel at the height of the melee that was underway surrounding the events of the car bomb discovered in Times Square. Needless to say, traffic through the Holland Tunnel neither was less than forgiving nor was that which we encountered on way to Queens any better as a result. On the trip into the city news commentators could be heard speculating with respect to the cause of this event. Why would a young, respected young naturalized American citizen (Faizal Shahzad), find it acceptable to place a makeshift bomb in Times Square? What was his reasoning? His goal? His message? Who was behind the activity and what might be the logical extension seen as a result of this event? All valid questions. All seeking validation with respect to understanding whether or not the causality associated with these questions and the event in question (not to mention the young man), was in fact deterministic in origin or random. We know that it was in fact not random based on evidence that had been collected and authorities are continuing to investigate the events that lead to this event and ultimately influenced it from the perspective of cause. We humans tend to this with all manner of things ranging from the serious to the trivial.
With respect to information security or security in general, I believe we do so more often than people realize. Security or being secure, is in many respects dependent upon being able to detect, identify and observer causality. In being able to accomplish these three things, we are better positioned to account and prepare for the unknown. If you stop to think about that for a moment it should become quite clear that the act of securing anything – home, car, host, server, network, people – requires the acknowledgment of historic reasoning (in both deterministic philosophy and randomness), while at the same time the acknowledgment of the unknown.
We see this often within the friendly confines of our industry. Take for example the following: An organization is instructed by a governing body that in order to achieve a state of conformity with its governing body the organization in question must meet and demonstrate achievement of x number of criteria. Failure to do so will result in negative ratings that may or may not result in fines and / or the inability to conduct business transactions. The governing body assumes that arriving at a state found to be in alignment with its standards will discount and eliminate (due to deterministic causality), any potential for randomness to manifest, thus negating the possibility. But what if their assumption is wrong? What if the data which they have assumed to be whole and comprehensive is not so?
I fear that this is more common than not within our space due to a lack of due diligence and grasp of historical accuracy with a forensic like precision.
Here’s another example:
A software-publishing house for quick processing of financial transactions develops an application. It is seen as being mission critical to organizations that purchase it looking to capitalize off of any edge they can to beat their competitors to the market. Speed in this case is very good. The software publishers, realizing the importance and value of the application to their clientele decide to expeditiously develop and push the code to market rushing through all quality assurance (QA) and beta testing in order to beat the deadlines set by the executive teams in order to realize the greatest degree of revenue possible. The developers run through the exercise of white boarding the data flow and block diagrams, technical requirement documentation, marketing requirement documents and product roadmap documents. From there the code is pushed through the QA gauntlet at light speed and rushed into the beta testing customer environments. Initial results are noted and brought back to product management and engineering who then wrestle with addressing the issues in a timely fashion in order stay within budget (both financial and time budgets), while not missing their window of opportunity within the market space. The code is run through QA again, and pushed for GA candidacy.
But there is a fly in the ointment. Some young (or not so young), perhaps charismatic (or at the very least quirky), individual is asked to look at the code or application as part of an audit and assessment and finds that low and behold it is vulnerable to an abundance of potential threats all of which can be exploited in a trivial manner. At the same time this assessment is occurring the code and its publishers are reaping great successes and accolades. The code, now a fully baked financial suite is swiftly on its way to becoming one of the most popular suites of its kind in 21st century business; yet, it is as vulnerable to exploitation as a runaway at a Port Authority bus station. While our young or not so young, assessor of questionable charismatic quality, is reviewing the code, carefully noting the deficiencies and potential for complete exploitation, reports begin trickling into our software publisher that exploitative events have begun. Worse yet, they were events that were not accounted for during initial or secondary quality assurance testing and thus perceived as being random. We know however that randomness is simply the failure to take note of events that feed into causality, which therefore can be interpreted as a failure in paying attention to detail. Perhaps one of the gravest mistakes anyone can make yet all too common within our world and history, let alone our industry. So what are we to do about this? How can we, as professionals convey a sense of urgency that supersedes and avoids a “chicken little” like knee-jerk response to events we encounter? This is easier said than done especially in a world where information travels at the speed of light. I believe that in order to achieve the proper perspective we need to encourage the following:
- a healthy respect for that which is known or what we know to be true
- a healthy respect for the known or what we are not sure of
- an acceptance of our current posture as we understand it
- a recognition of our strengths as we are aware of them
- a recognition of our weaknesses of weaknesses as opposed to a denial of them
- an ability to process this information and begin formulating a plan
- The ability to execute that plan and due course perpetuate its repetition in order to avoid falling victim to said trappings.
This is by no means a trivial event; nor has it ever been an easy proposition. The ability to interpret historical events and data — even when they appear to be disparate and unrelated is paramount to achieving the goal of comprehensive deterministic understanding. In short this allows us to avoid via scientific means the pitfalls associated with randomness and its associated theories. In order that we may achieve this the ability to reflect upon our data sets and circumstance all while applying observing ego is of paramount importance.
Threat Modeling
Threat Modeling
For most of us, the concept of ‘Threat Modeling’ takes on different meanings based upon our experiences, areas of expertise, areas of interest and comprehension of what constitutes and is defined as a ‘threat’ by industry and by ourselves. For man, ‘Threat Modeling’ is the realm of the developer. It is an area of expertise, which specifically addresses security, concerns of interest to them while for others, ‘Threat Modeling’ is used during assessment work. It is during these assessments, most of which are specific to code analysis and review, which we see many use these techniques to formulate and define more robust ‘Threat Models’ vis a vis the definition of potential attacks and exploits. Regardless of the definition you subscribe to, we can assume that ‘Threat Modeling’ accounts for much, but does it account for everything we need it to?
Threat Modeling Attributes
It’s important to note that ‘Threat Modeling’ has undergone much change over the last decade. It has experienced evolution and likely will need to going forward as both the application of the act of ‘Threat Modeling’ as well as the philosophy behind it, continues to evolve and grow. This is really rather non-negotiable when one looks at the current state of technological advancement we are in today and where we dare to take ourselves. As a result, we can assume the following of ‘Threat Modeling’:
- There are traditionally three commonly held views of ‘Threat Models’
- Attacker Centric
- Application / Software Centric
- Asset Centric
- ‘Threat modeling’ can be related to any asset deemed to posses worth and be considered of value to an individual or organization
- Personnel
- Facilities
- Applications
- Systems
- Networks
Identification and declaration of exactly what defines an asset is crucial to the process of ‘Threat Modeling’, failure to perform due diligence here will be noted and likely lamented in post mortem investigations.
- It is the desire of the owner or the party(s) tasked with stewardship of the asset in question to protect and ensure the safety of the asset (and any associated / related assets)
If there is any doubt as to whether or not it is the intent of those tasked with responsibility and stewardship for all defined assets, ‘Threat Modeling’, though still important should not be the first order of business!
- All assets have points of vulnerability
- All points of vulnerability can be exploited if left unaddressed or if addressed in appropriately
- Vulnerabilities can be exploited via internal or external means
We live in an imperfect world and as a result, all things; even the most cleverly engineered – organic or inorganic, have flaws. Assuming otherwise is a failure of logic and will almost always lead to a fall. Accepting that all things have vulnerabilities and are susceptible to exploitation knowing that these vulnerabilities can be remediated and the risk mitigated is of paramount importance to the success or failure of ‘Threat Modeling’ exercises or any associated activities.
- Useful in developing in countermeasures
This is of course quite elementary and obvious yet it is something that needs re-enforcement for several reasons not the least of which is that many despite this obvious benefit or by product depending on your point of view, still will not endeavor to engage in formalized ‘Threat Modeling’.
- Can be focused on defense or offense
This, I believe is self-explanatory as one might, again taking into consideration their working definition of ‘Threat Modeling’ into account either look at is as a defensive activity as we discussed earlier or as a mechanism useful, if not paramount, in offensively compromising an asset.
Where to Begin With Threat Modeling?
At a very base level, one needs to ask oneself some key questions prior to engaging in the activity of ‘Threat Modeling’ in order to avoid any oversights or mistakes. These questions are rather elementary yet their value cannot be emphasized enough. They provide the ‘looking glass’ if you will, which is necessary in order to successful model threats and gain the most value from the activity. Some of common questions which one should endeavor to ask and answer may look like (but by no means need reflect verbatim):
- What are the assets you need to protect?
- Where do they reside?
- Who are your customers? User community?
- Who are your adversaries?
- What are your strengths?
- What are your weaknesses?
- What can be done to minimize the attack surface and mitigate risk?
- How often should you engage in this process?
In going through this exercise, trivial though it may seem, a great deal of valuable information and data points may be collected and assessed for their use and application during ‘Threat Modeling’ activities.
Models At Our Disposal
There are many models currently in use today. Some are more focused or directed towards developers while others focus more on the needs of assessors and auditors. Regardless there is no one single way to go about conducting ‘Threat Modeling’. Below are a few wonderful examples of current ‘Threat Modeling’ methodologies & resources:
A View To A Kill: Executing a Threat Model and Processing The Results
- Picking Your Poison: Deciding on Threat Model
- Executing a Threat Model after exhaustive data gathering & analysis of said data
- Post Mortem: Examining the Remains
- Lessons Learned: Planning for the Future
- It’s a Cycle: Wash, Rinse, Repeat
Conclusion:
The value presented by the activity associated with ‘Threat Modeling’ is difficult to argue against. ‘Threat Modeling’ provides a vast amount of data and can aid both individuals and organizations (in quantitative and qualitative terms), in a multitude of ways not the least of which is providing clarity into the vulnerability of an asset or potential for exploitation of an asset. Failure to undertake these activities is akin to dereliction of duty for developers and assessors alike as those with nefarious intent not fail to exhaust every measure at their disposal to accomplish their mission.
Accountability the Non-Negotiable Asset
In business, accountability is something that cannot be stressed enough. This was true before the economic breakdown of 2009, and will continue to be long after. Accountability is of paramount importance and perhaps more so than anything else, it is a good thing. Accountability is something that at some base level, all humans can relate to. Ask any child whether or not they receive reprimanding by their parents when found to be in violation of a rule and you will almost assuredly receive a response of ‘Yes’. If you receive a ‘No’ than perhaps, that is a sign of bigger challenges and problems to come. Regardless of the response, my belief is that you would be hard pressed to find anyone with any amount of intellectual honesty who would say that being accountable is a bad thing.
Accountability is a good thing. It is of imperative importance. Accountability aids us in the definition; maintenance and articulation of healthy boundaries that all humans need and require (though are not always seen or found present). Boundaries, rooted in the freedom afforded by accountability, enable us to live, grow and prosper with the understanding that we are all responsible for our actions (of course there are things which we cannot control however our responses to external stimuli as Marcus Aurelius taught us, are well within our sphere of influence). Accountability provides much more in the way of freedom than most would initially suspect.
As information security professionals, we should all (I will not assume that all do however, I will suggest that we all should), be cognizant of the value of accountability. If one looks at the continuum of information security, and its role within modern business today (regardless of the vertical or sector), one can conclude that being accountable should not be negotiable. We do not live in a perfect however and as a result, we must assume that in some organizations, for better or worse, it will be seen as being negotiable. In those cases where it is deemed negotiable, one need not look any further than to the leadership in place and their vision for both the culture. Similarly, in those environments where it is deemed unacceptable to be negotiable with respect to accountability one need not look any further than the organizational the leadership teams. When moral flexibility is allowed to negatively influence accountability, it should surprise no one when armies of auditors, assessors, consultants, vendors descend upon the environment in question to aid the bewildered, understaffed information security teams and management. There is blood in the water and sharks can smell it for miles off.
The impact upon the organizational culture, receptivity and tone becomes more pronounced as well. The cultural attitudes of the organization in question, in addition to the sub-cultures that exist within the primary organizations business units. Any number of scenarios can come about as a result from those that are extremely open, productive and collaborative to those that are terribly conflicted and shut down from a productivity perspective. Enterprises (whether in the public or private sector), do not need to settle for scenarios which encourage mediocrity and closed minded attitudes. The establishment of accountability as an elementary aspect of organizational culture and politics (social and / or formal), is a wonderful place to begin. This does not mean that organizations should begin encouraging Orwellian information gathering campaigns where rewards are given to those who inform on their co-workers infractions (real or perceived), but rather where all parties from within all roles understand their contribution to the organization in any and all forms to and including being accountable for ones’ own actions and to one another so as to prevent any damage to the organization and / its assets (tangible and intangible alike).
You might be saying to yourself as you read this “that sounds wonderful Will, however I live in the real world and work there to. I have no use for esoteric philosophical idealism when I need to get the job done today, especially when I have to demonstrate compliance for God knows what to God knows who”. Fair enough, I can appreciate that which is exactly why reply would go something like this “Of course you don’t, you’ve got a lot to accomplish in little time and with even less in the way of resources however if you take a few steps back from the situation, employing observing ego you will see that the advocacy of accountability in the form I am speaking of (predominantly through sound risk management based security programs and frameworks), would relieve you of much (not all), of the challenges you face”. Crazy you? Unrealistic? Immature? Handsome (had to throw that in to see if you were paying attention 
. My assertion is that through the adoption of a solidly crafted risk based security program and framework; accountability can be achieved where it currently does not exist and supported & enhanced where it already does so.
So how do we get there from here in the absence of accountability? The first step is to revisit your organizations P3 (process, procedure, and policy) to see what exists (if anything), to do date. Odds are, something does though the state and maturity might vary. Should you find yourself in a situation where you have none or what is roughly the equivalent of none, fear not. This is not necessarily disastrous however, it should be addressed and amended swiftly in order to ensure the organization maintains its risk posture or, at the very least, becomes cognizant of it.
On Monday January 4, 2010 Information Infrastructure Solution Giant, EMC agreed to acquire Overland, Kansas based Archer Technologies for an undisclosed amount (Archer Technologies is privately held) and anticipates completing the acquisition sometime before the end of Q1 2010. I am slightly annoyed by this as I love Archer Technologies products and think they do a smashing job in the GRC (Governance Risk Compliance) software space however, I am happy for the Archer folks all the same if the deal works to their collective best interests and those of their collective clients and customers. Art Coviello, President of RSA, which has for a while now been the Security Division of EMC summed it up the reasoning for the acquisition best saying that traditional security management focuses primarily on addressing technology issues but their customers were telling them their real challenges came in the area of policy management, audit and compliance. He concluded by saying “You can’t manage what you can’t see”, a fair point yet rather pedestrian for those more fluent in information risk management where the real challenge is not being able to secure what you are not cognizant of. It seems as though Archer Technology will live within the realm of RSA and likely be integrated or, at the very least coupled with RSAs’ SIEM solution, Envision.
All of this is goodness for the end customers and clients of EMC’s current solutions and could prove advantageous for Archer Technologies legacy customer base as well. Tools such as Archer are wonderful for influencing and bringing to bear properly architected risk based process, procedure and policy frameworks while identifying deficiencies where they exist. The challenge is that Archer Technologies does not have legitimate actuarial based data as do vendors such Prevari, which enables you to establish sound metrics against the enterprise. Was I working with Mr. Coviello I would have recommended purchasing both as one without the other is good, but both demonstrate a more sophisticated and complete view of an enterprise world.
So what will become of Archer? As mentioned previously we shall see it working with the RSA suite and if EMC can pull it off, their Ionix unit that aids customers in automating their IT configurations across servers, networks, and storage environments. This would be exciting for enterprises and could prove hugely influential in EMCs maturity as a security player in addition to their ability to provide more robust solutions geared towards governance and risk management. Jon Olstik of Network World wrote a wonderful blog post on this topic stating the following for EMC’ choice and reasoning in acquiring Archer Technologies:
- An enterprise GRC architecture:
- RSA will integrate Archer and enVision into a multi-tiered architecture. The bottom tier will be log management (i.e. data collection, processing, and storage). The middle tier will be data services (i.e. middleware-like functionality including data translation, transaction services, etc.). The upper tier will be dedicated to data analysis. This analysis is dedicated to security and compliance today but it could be used for network operations, capacity planning, and business queries in the future.
- Strategic services:
- With Archer in tow, RSA becomes one of few vendors who can help companies align security and compliance with business processes. Yes, this will drive product sales but it will also help EMC create valuable strategic services and capture lots more services revenue.
- A bridge to IT Service Management:
- Aside from security and compliance, EMC is also pushing hard into ITSM with its Ionix product line. EMC will integrate Archer and RSA together linking log management with the CMDB as well as change, patch, and configuration management. In this way, Ionix can help enterprises automate compliance and security management response.
I do not believe this will be an easy task for EMC / RSA to accomplish. They are facing some incredible technical integration challenges with this acquisition and their intended integration strategy. Between their platforms and will no doubt struggle to define and articulate a realistic product road map that represents their vision and capabilities to current and prospective customers & clients alike.
What is Security Research Worth?
Recently I’ve been giving thought to the value of security research and what a customer might pay for access to information collected by an organization with an expertise in assessing technical threats and vulnerabilities, government mandates and geo-political climates and then applying this knowledge to information security programs and practices. There are very likely two knee-jerk responses to this with one being, “Why would I pay for something my people can research on the internet?” and the other might be “Well, if I can get true value to increase the security posture of my organization, sure I’d pay for it.”
In either case, we still don’t know how much we should be paying for this research. I would say that we must first start with figuring out what it would cost an employer to hire an experienced security analyst or engineer, who is then dedicated to this function. According to Payscale.com security specialty pay ranges from $63,000 on the low end to nearly $100,000 per year on the high end. Add to this another 35% for benefits and you have a $135,000 per year experienced employee to spend their entire day collecting information from various websites and other resources. But remember that this person will only work about 40 to 50 hours per week, so what about the rest of that time?
So let’s assume that you have a relief factor .7 (standardized for the private sector) so the number of persons needed for a single position is 1.7 to take into account weekends, vacation and sick time. That said, if you’re going to staff 3 positions to achieve 24×7x365 security research and analysis capabilities, the number of people needed for that team is 5.1 (we’ll round it down to 5) so the total employee cost for a year is $675,000 plus training and education costs.
Ok, I know that I’m making some assumptions here and the actual salaries could be higher or lower depending on market, candidate, etc. Also, I’m making the assumption that an organization would require 24×7x365 staff to perform full security research, analysis and monitoring of the threats, vulnerabilities, market factors and geo-political factors that could impact their critical systems and networks. By the way, security research does not refer to the need to manage their security infrastructure for specific, targeted events against their infrastructure.
This brings me back to my initial question. Is there value in holistic, independent security research? Would you pay to have access to this information?
I’m certain there is and I would urge you to consider the following as you consider the value of this information or type of service to your organization.
At a minimum the following information needs to be available to the customer:
• Daily reports on the latest trends, threats, vulnerabilities and other issues that are relevant to the customer’s business or market
• Access to up to the minute threat and vulnerability data that allows an organization to customize and select security information relevant to their infrastructure
• Relevant information that covers not only technical threats and vulnerabilities but also anything specific across markets, geographies or political situations which can be used for an organization to understand the full impact of technical and geo-political events to their organizations
If a research organization can provide this type of information to a customer in a manner that doesn’t compromise their intellectual property or competitive advantage in a marketplace, there is certainly significant value to the customer. I just don’t know how much they would pay for this data. What would you?
The Payment Card Industry Data Security Standard (PCI DSS) is not the devil incarnate but comes under scrutiny (for good reason – a great deal of which has less to do with the standard itself and more to do with the organizations wrestling with it along with the credit card corporations themselves), likely as often as the devil himself. Before PCI was PCI, before there was this digital equivalent to “reefer madness”, where fear, uncertainty and doubt solely relegated to the world of the payment card and their affiliated merchants and provider – banking environments seemed to permeate every fiber of the tapestry of the Information Technology and Information Security worlds, all the bigs – Visa, MasterCard, American Express, Discover Card (aka Discover Financial Services), Diners Club and JCB International, all had their own ‘ways’ of assessing the security posture of their vendor / provider networks. Some were more inclusive and detailed than others. That is a fact.
It was ugly, it was cumbersome, it was ineffective and it warranted change as the credit card corporations and their affiliated banking partners were experiencing fraud and exploitation in a variety of ways from a variety of sources, which ultimately led to a convergence occurring within that world. A convergence which would have impact upon us all for years to come…like chocolate and peanut butter only not as good. Initially this did not seem like a bad thing. In fact, I happen to believe it was necessary in small scale to aid in jump starting awareness. I am proud to be personally acquainted with the primary architect of the original draft of the first PCI standard and know where his mindset was when he drafted it. I know his intentions were pure with respect to this standard. Furthermore, I also know that he did and does not believe the PCI DSS to be a legitimate replacement for sound risk management practice but rather a starting point for many organizations, which had no bearing point. Fair enough. I think we can all accept that, at least those of us who are intellectually honest. What happened? Why all the hub-bub? How did something which started out with solid intentions turn into this new and creative form of audit water torture which often yields little in the way of sound risk posture aside from gaining PCI accreditation…for what that is worth…I’m guessing the folks at Hannaford Supermarkets, Heartland Payments and Choicepoint (parts I & II) know what I’m talking about.
The PCI Standards are easily had these days as are lists of authorized assessors however, just because they are easily had (both the ‘standard’ and the assessors) does not mean they are effective. In many respects, PCI reminds me of the early days of HIPAA, the difference being that with PCI people actually being penalized for failing to comply. Sort of a novel idea really however I believe that that regulatory and auditing criteria (standards) – important as they are, in and of themselves do not meet the needs of enterprises small and large; private or public in our world today. What can meet these needs? (cue drum roll): Well designed business centric risk management security programs and frameworks. Are they trivial? No. No, they are not. However, neither is PCI, or HIPAA for that matter and whereas both PCI and HIPAA fall into the Sisyphean category in my view of the world, Risk Management does not, additionally, if undertaken risk management initiatives will provide an enterprise with a wealth of information which PCI never would (sorry guys), not on its best day. So the question (or one of them anyway), becomes: Why continue to divert time, effort, resources (personnel and budget), into something so one dimensional when a properly designed risk management based security program can address these and every other regulatory and compliance concern you’re presented with. The bit gods must be crazy…let’s read on.
I believe that the only way to rescue the hearts and minds (and ledger books!) of those responsible for budgets within industry is through demonstration of the intrinsic value of risk management (e.g. enterprise risk management, fiduciary risk management and information security risk management working in concert). This demonstration must be ubiquitous and comprehensive in scope to the enterprise in question touching all areas of the business: customers, business partners, P&L, revenue streams, brand preservation etc. This is something that I feel passionately about as do others within our industry. The fact is that as times and circumstances change (for better or worse), so too will budgets (for better or worse), and if initiatives such as PCI are not reconsidered (given the current volume of spend being seen as a direct result of meeting or achieving compliance with the standard) — in both scope and value, we may very well run the risk of encouraging and incurring new and previously unforeseen risk via new threat vectors previously not considered nor addressable due to a lack of budget (capital or operational), for investment in innovative technologies, processes and people.
