Thursday, January 26, 2012 at 1:54PM LASCON 2011: October 27, 2011
Matt Tesauro was the project lead for the LiveCD OWASP Project and is on the OWASP board. My notes are below...
Thursday, January 26, 2012 at 1:23PM LASCON 2011: October 27, 2011
Jeremiah Grossman is the founder of White Hat Security, where my good friend Stephanie Fohn is currently CEO (she helped us with our first initiatives and product launches at Tripwire over a decade ago, for which I'll be forever grateful). Jeremiah is also very well-known for his work on metrics and benchmarking all aspects of vulnerabilities.
Here are my notes/tweets from Jeremiah's presentation:
Thursday, January 26, 2012 at 12:50PM LASCON 2011: October 27, 2011
James Wickett and his ex-boss @ernestmueller are both a very special breed of people. James is well-known for his experience as an information security practitioner and his leadership in the OWASP community (he is the conference chair for the upcoming 2012 OWASP USA conference). But what makes him so interesting to me is that a boundary spanner. Beyond just infosec, he has experience doing IT Operations, as well as Development and DevOps practices.
(Incidentally, I believe his presentation on "The Rugged Way in the Cloud--Building Reliability and Security into Software" as one of the seminal works on how to information security integrates into DevOps-style practices. It is shown below, even though that isn't the topic of this talk note:)
At LASCON, he presented with Peco Karayanev on the PIE tool they built to integrate security practices into daily development and IT operations work. It will look very similar to a DevOps presentation, but hints at how organizations can integrate and deliver the non-functional requirements from the Rugged Computing initiative (e.g., scalable, available, survivable, securable, supportable, etc..).
Here's how they describe PIE, which is a tool they developed at National Instruments to support developing applications that are served up in the cloud:
DevOps, lascon, security/compliance, talks Tuesday, July 27, 2010 at 1:16AM I'm getting ready for my BSides talk on Wednesday on "Mobilizing the PCI Resistance." And I made a slide that was designed to hint that defining the scope of PCI assessment may not always be as easy one might think.
In today's blog post, I pose some (possibly trick) questions. But before I do that, to refresh your memory, here's what are the previous postings:
At one time, I believed that the Cardholder Data Environment being defined by where cardholder data "enters, is transmitted, processed, stored, displayed or printed" is sufficient to inform most scoping decisions.
Gosh, was I wrong.
Don't worry if the answers don't seem immediately obvious. I'd wager I would have gotten most of these wrong last year.
Question 1: Is the Cardholder Data Environment (CDE) equivalent to the PCI Scope of Assessment?
Question 2: Is a domain controller (e.g., Windows Active Directory server) that is being relied upon by CDE applications for authentication and security services in the PCI Scope Of Assessment?
Question 3: How about a domain controller (e.g., Windows Active Directory server) that is not relied upon by any CDE applications?
Question 4: Is a network attached stapler that happens to be on the same network segment as a CDE system component always also in the CDE?
Question 5: Does it matter if a workstation that a customer service representative uses a thin- or thick-client?
Question 6: When should it be acceptable that if a virtualization hypervisor hosting a production application in the CDE be also able to host another VM without it being part of the CDE, as well?
Question 7: If you have a domain controller that is not in the CDE, but in the scope of PCI assessment, is a print server on the same network segment as that domain controller also in the scope of PCI assessment?
Bonus Exercise: For each of the questions where you answered "in scope of the PCI assessment," describe a strategy to contain the scope, such that systems connected to that system are not in scope. (See Michelle Klinger's great post on the "PCI Contagion Dilemma.")
(Image courtesy: Flickr: Zeligfilm)
The answers for all of the questions is actually, "It depends." But just as problematic is the fact that people could arbitrarily disagree with your answer, with little ability to defend its validity. The trick is being able to state, "Yes, it depends, but on what does it depend upon?"
Also, generating a consensus on scoping conclusions takes a lot of time. Prior to creating a structured method with agreed upon definitions, the Scoping SIG required over 40 hours to come to a scoping conclusion for one scenario.
With the proposed guidance under development, our team was able to generate a consensus on 15 scoping conclusions in less than 2 hours.
We believe there are three things needed to aid the scoping effort, and be able to defend your answers, so that another person can follow your reasoning. Even if they don't agree with your scoping conclusion, at least they can scrutinize your assumptions.
My goal is to have the PCI Scoping SIG deliver;
Interested?
GAIT, PCI, security/compliance Tuesday, June 29, 2010 at 6:20AM This is Part 6 of the "Mobilizing PCI Resistance" series. Briefly, we've covered:
The GAIT project was one of the most politically charged projects I've ever been involved with. The diagram below shows each one of the constituencies, and the relationships between them.
As we go through them, I'll discuss the equivalents to the PCI universe. I posit that while the PCI ecosystem is also very political, it's less so than for SOX-404. This is good news. :-)
My reason for this blog post is to describe how we analyzed the lay of the land, and created a winning strategy that allowed us to change the compliance landscape. By doing this with PCI, we can play to win.
(By the way, this type of diagram is called a "value network," and was taught to me by the famous Eileen Forrester at the Software Engineering Institute at Carnegie Mellon University. Full slides available on SlideShare)
So, let's go through each of primary constituencies, and then I'll discuss how they relate to each other:
The Sarbanes-Oxley Act of 2002 was enacted as a response to accounting scandals at WorldCom, Enron, Tyco International, etc.
The Securities and Exchange Commission (SEC) created a new set of requirements that public companies (i.e., "SEC registrants") had to comply with.
The Public Corporation Accounting Oversight Board (PCAOB) was created by SOX-404, charged with overseeing, regulating, inspecting and disciplining accounting firms in their roles as auditors of public companies.
In other words, they audit the auditors. For instance, on at least an annual basis, they would audit the work papers submitted by the Big Four firms to ensure the quality of their work, and that it's in compliance with the standards of independence. Each year, they would publish a report describing when the external auditors behaved in ways that was "out of line."
The PCI equivalent here is the PCI Security Standards Council and the card brands. The parallels between the PCAOB and the new PCI requirements for QSAs to submit their work papers and Reports on Compliance (ROC) is striking. PCI is now actively auditing the auditors.
CEOs and CFOs: These are the people specifically named in SOX-404 as personally accountable and responsible for the effectiveness of controls that support the accuracy of the company financial statements (e.g., 10-K statements submitted to the SEC).
When people make jokes about "keep the executives out of orange jumpsuits" or "keep them out of jail," these are the people who would be wearing them.
CIOs and IT Management: We identified that one of the primary contributors around the wasted time/effort in support of SOX-404 was in the domain of IT controls. Business management owned the financial controls, and IT management owned the IT controls.
Information security: More specifically, many of the IT controls were owned by information security.
The PCI equivalent here are the merchants, service providers, and anyone else who has custodianship of cardholder data. These are the people who are often complaining that the PCI DSS is too subjective, too arbitrary, that the cost of compliance is too high, etc.
And again, this is the likely the community we must mobilize first.
Internal auditors are independent of Business Management and IT Management. Their goal is to ensure that the risks to the organization are understood and that adequate controls exist to prevent, detect and correct for those risks.
(Interestingly, in my experience, in most organizations, internal auditors are only recently showing up at the table for PCI compliance. But, they have a wealth of experience to bring in terms of managing external auditors. And it's my understanding that internal auditors can now submit PCI Reports On Compliance now, even though they're not technically a QSA.)
External auditors generate an opinion on the financial statements. They also have their work papers audited by the PCAOB.
The PCI equivalent here are the Qualified Security Assessors (QSAs). Instead of generating an opinion on the accuracy of financial statements, they file a ROC.
The IIA was clearly at the forefront of this issue, and this is the community we mobilized. (ISACA was peripherally involved in the beginning, but dropped out due to unbelievably bad relationships between them and IIA.)
(In the PCI world, I'm not sure if there is a professional organization that we can mobilize. Instead, I believe the best lever is the PCI Community of Participating Organizations.)
The constituency who probably saw the problems the clearest were the internal auditors, who saw that the amount of investment in IT controls were way out of proportion to the risk. While other constituencies also saw the problem, we believed it was the internal auditors who could describe it most clearly, and could mobilize a response.
We then gathered the heads of audit (and sometimes IT audit) from some of the largest publicly traded companies. Our goal was to assemble the auditors from top Fortune 50 companies, and have them uniformly say, "we all see a common problem, and it is causing significant economic harm. And we have a joint proposal for what we should do about it."
As mentioned in a previous blog post, the initial companies involved included General Motors, Wal-Mart, Hewlett Packard, Intel, Microsoft, Marathon Oil, Chevron Phillips Chemical, Business Objects, etc.
When those companies start screaming, people listen.
Now that we had an impressive list of publicly traded companies all saying we had a problem, the next step was to engage their audit firms.
We had each one of the audit executives reach out to their IT audit engagement partners, and invite them to the GAIT summit. We selected and organized the companies to ensure that we had coverage of each of the Big Four firms (i.e., PwC, KPMG, E&Y and D&T). This was framed as a strong request to the Big Four firm, along the lines of, "I believe that it is very important for the relationship between our two companies that you personally attend this summit. And I'd like you to bring someone from your national practice, as well."
That last request was important, because the goal was not to change the IT scoping practices of, say, E&Y and Microsoft. Instead, the goal was to affect all of the engagements that E&Y was involved in. The national practices at the Big Four firms are usually responsible for establishing the standards, practices and procedures for the entire organization. They're typically some of the most senior and experienced partners, as well as promising staff members likely to become partners. Why would they want to attend?
This was probably one of the biggest obstacles to the GAIT initiative. How could encourage or compel the Big Four firms to participate? A cynical person would say that there was no real reason for them to get involved, as GAIT would do the following:
Our solution was to make sure that Bill Powers from the PCAOB attended each of the GAIT Summits. The goal of GAIT transformed then to ensure that IT work performed in support of SOX-404 represented a continuation of the top-down, risk-based approach described in Auditing Standard 2, a publication published by the PCAOB. The implication is that the PCAOB would be very interested in any Big Four firms who did not want to participate in the GAIT process.
Now we had assembled each of the constituencies required, each that could achieve a desired outcome out of a successful GAIT project.
Next up, I'll pose some thought-experiments on PCI scoping, and walk through the GAIT Principles.
