Last week Will “harmj0y” Schroeder published an excellent technical article titled “Not A Security Boundary: Breaking Forest Trusts” in which he lays out how a highly critical security compromise can be achieved across a forest boundary, resulting from a combination of default AD (security) settings and a novel attack method. His post is a follow-up to the DerbyCon talk “The Unintended Risks of Trusting Active Directory” which he had given together with Lee Christensen and Matt Nelson at DerbyCon (video here). They will also discuss this at the upcoming Troopers Active Directory Security Track (details on some more talks, including Sean Metcalf’s one, can be found in this post or this one).
This is the first post discussing talks of the Active Directory Security Track of this year’s Troopers which took place last week in Heidelberg (like in the last nine years ;-). It featured, amongst others, a new track focused on Microsoft AD and its security properties & implications. This was the agenda.
I gave a presentation on Cloud Security, Compliance & Trust the other day. The basic message was to look beyond the Cloud buzzword and see the actual technologies which are used, understand which security principles still apply and which need to be re-thought, giving a rough direction about regulatory compliance in Cloud environments (which of course is non-binding, as I’m not a lawyer), and the importance of trust evaluations (especially) when it comes to Cloud services.
A few days ago (on 10/12/2011) Apple launched its new cloud offering which is called — who would have guessed 😉 — iCloud. Since we’re performing quite some research in the area of cloud security, we had a first look at the basic functionality and concepts of the iCloud. Its main features include the possibility to store full backups of Apple devices (at least, an iPhone, iPad or iPod touch running iOS 5 or a Mac running OS X Lion 10.7.2 is required), photos, music, or documents online. The data to be stored online is initially pushed to the cloud storage and then synchronized to any device which is using the same iCloud account. From this moment on, all changes on the cloudified data is immediately synchronized to the iCloud and then pushed to all participating devices. At this point, most infosec people might start to be worried a little bit: The common cloud concept of centralized data storage on premise of a third party does not cope well with the usual control focused approach of most technical infosec guys. The resulting concerns can be attributed to several main cloud computing related risks (which are proposed by ENISA and actually very valuable work:
Lock In: According to the way the cloud functionality is integrated into iOS and OS X , usage of the iCloud might result in strong lock in effects. There is neither the possibility to use different backend cloud storage for the functionality nor the possibility to develop a product which provides similar functionality (see later paragraphs for examples).
Isolation Failure: is probably the most present threat for many IT people, since it is highly related to technical implementation details. It includes, but is not limited to, breakout attacks from guest systems due to vulnerabilities in the hypervisor or to unauthorised data access due to insufficient permission models in backend storage. Thinking of the trust factor consistency, Apple’s history of cloud based services was not their “finest hour” (as Steve Jobs stated during his keynote on iCloud). Remembering this talk and the awkward MobileMe vulnerabilities, we would agree with that 😉
Loss of Governance: The loss of governance over data in the cloud is kind of an intrinsic risk to cloud computing (also refer to the proposed system operation life cycle and the motivation given here). Again, referring to explanations about the technical iCloud implementation in the later paragraphs, this loss might be even more relevant in the iCloud environment.
Data Protection Risks: Handing over responsibility for the storage of data to the cloud service provider, a customer also hands over the possibility to protect his valuable (or more concrete: personal) data by controls of his choice. Reviewing Apple’s terms of service for the iCloud, the following paragraphs are somewhat related to data protection issues: You understand that in order to provide the Service and make your Content available thereon, Apple may transmit your Content across various public networks, in various media, and modify or change your Content to comply with technical requirements of connecting networks or devices or computers. You agree that the license herein permits Apple to take any such actions. And in addition, the Apple Privacy Policy states the following: You further consent and agree that Apple may collect, use, transmit, process and maintain information related to your Account, and any devices or computers registered thereunder, for purposes of providing the Service, and any features therein, to you., which kind of reminds of the Dropbox Terms of service which even state that they are allowed to transfer your data to anybody if it is necessary in order to assure the quality of the offered service. Thinking of the trust factor components, all of these risks are getting even more relevant since Apple relies on third party cloud services (which are Amazon Web Services and Azure, according to several sources, including this one), which conclusively must also fulfill certain security requirements in order to lower the vulnerability factors for the presented risks.
There are some more risks according to the ENISA study, but those are beyond the scope of this post. If we do such rough assessments as sample exercises during our cloud security workshops, the participants usually ask what “they can do”. Possible controls can be divided into two groups: controls to reduce the risk to a reasonable level and controls which prohibit the usage of the particular service. When analyzing the cloud, the control always mentioned first is crypto. Speaking of cloud storage, crypto is a valid control to ensure that unauthorized access (e.g. due to isolation failure/physical access/subpoena) to data has no relevant impact. The only requirement is that the encryption is performed on client side (depending on the attacker model and whether you trust your cloud service provider). For example, Amazon provides a feature which is called Server Side Encryption which encrypts any file that is stored within S3. Additionally, Amazon allows the implementation of a custom encryption client which enables customers to perform transparent encryption of all files which are stored in S3. The analysis of the security benefits, attacker models, and operational feasibility of these controls will be the subject of yet-another blogpost, but at least Amazon offers these encryption features. The offered services of the iCloud differ a little bit in functionality (for example, the iCloud iTunes version is a kind-of music streaming platform), but basically there are two API functions which allow access to the iCloud backend. First, it is possible to store documents (where documents can be complete directory structures) in the iCloud, second, a so called key-value store can be accessed. The access is encapsulated in dedicated API calls which take care of the complete data transfer, synchronization, and pushing operations using an iCloud daemon. So any use of the iCloud is strictly connected to an app (I would have called it application ;-)) which has to use the introduced iCloud API calls. Even though I’m not that familiar with the iOS/OS X architecture, I would have guessed that it would have been easily possible to add client side encryption using the internal keychain and usual cryptographic mechanisms. Still, this is not the fact and it is questionable, regarding the user experience oriented focus of Apple, whether this feature will be implemented in the future. This lack of encryption possibility brings up the second class of controls, which shall restrict the iCloud usage. This is especially important in corporate context, where full backups of devices would potentially expose sensitive corporate data to third parties. Even though the usage might be restricted by acceptable use policies, this might not enough since the activation of this feature can happen accidentally: If a user logs in once into the iCloud frontend, which is possible using a regular apple ID, the data synchronization is enabled by default and starts immediately (refer also to the quoted terms of service above). Since most corporate environments use MDM solutions, it is possible to restrict the iCloud usage at least for iOS based devices. The corresponding configuration profiles offer several options to disable the functionality:
allowCloudBackup
allowCloudDocumentSync
allowPhotoStream
For today, this little introduction to iCloud and some of its security and trust aspects will be finished here. We will, however, continue to explore the attributes of iCloud more deeply in the near future (and we might even have a talk on it at Troopers ;-).
After having introduced the basic elements of our concept of trust, control and confidence in this post, today I’ll try to strengthen your (and maybe even my own as well ;-)) understanding of these ideas by applying them to another candidate, that is Dropbox. Hence this post is mainly about performing a certain analysis method to some object; conclusions as for the question if Dropbox is suited to be used in enterprise environments processing sensitive data are out of scope and are left entirely to you, the valued reader.
Two more preliminary remarks might be helpful to further understand the direction and intent of this post:
a) I don’t have any practical experience with Dropbox. I don’t use it personally and at ERNW using it for company-related data would require a risk acceptance, which – probably not too surprisingly – no company member has ever filed (and which would have a quite high likelihood of being turned down by the CEO anyway ;-)). In other words: I can’t imagine any occasion we’d use cloud based storage services for any of our data. It’s just that – given our idea of “highly skilled, thoughtful and responsible humans working here” – we don’t use terms like “xy is strictly forbidden” very often…
So feel free to jump in by PM or comment to this post if this stated lack of practical experience has lead to wrong conclusions or factual errors.
b) This post is not about blocking Dropbox in corporate networks by technical means (which – afaik – is relatively easy compared to, say, blocking Skype, as DB seems to operate mainly from a well-defined /24 network range). Doing so (technically blocking DB on corp firewalls) would not solve the underlying problem of potentially misplaced trust (or ignorance) and might just lead to yet-another-risk-acceptance popping up on the ISOs’ desks (I know, I know: some of you would be happy if at least a risk acceptance existed for DB within your organization…). And, of course, the corp_fw way would not address the aggregate problem of running Dropbox on mobile devices (at least assumed that no cloud based proxy services are in use for those, which is currently the case in most networks I know).
However this post is about asking a certain set of questions and clarifying some company’s or service’s attributes to induce a reasonable discussion about the exact company’s/service’s suitability for processing sensitive assets. To us, such an approach is aligned with our understanding of an ISO as a trusted business advisor (as opposed to the “paranoid pitbull” or “unfortunately unheard master of governing guidelines” mission understanding of ancient times).
Now let’s have a look at the object of today’s trust exercise, that is Dropbox. Founded in 2007 and fueled by US$ 7.2 million venture capital (as of this Forbes article) the California-based company provides cloud-based file storage services with a simple GUI and some nice collaboration capabilities for groups of users sharing files. The description in the CrunchBase profile goes: “Always have your stuff, wherever you are”. A technical overview can be found in this paper recently presented at USENIX Security.
As you might recall from the first post of this series, there I laid out some trust contributing factors, which I took from the ISECOM “Mastering Trust” methodology that is taught in their Trust Analyst course (pls note that my interpretation of these may be wrong as I never attended that course. sorry, Pete ;-)).
These are:
Size – “Who exactly are you going to trust?”
Symmetry – “Do they trust us?”
Transparency – “How much do we know about $TRUSTEE?”
Consistency – “What happened in the past?”
Integrity – “[How] Do we notice if $TRUSTEE changes?”
Value of Reward – “What do we gain by trusting?” (that’s the one that Ponzi schemes are based on)
Components – “Which resources does $TRUSTEE rely on?”
Porosity – “How separated is $TRUSTEE from its environment?”
Applying all these to Dropbox might yield the following answers:
a) Size
While this might seem a simple one given Dropbox is a not-too-big company presumably held by their founders and some investors/venture capital providers (plus maybe employees holding stocks or options or sth) it should be noted that, more or less obviously, there’s more entities in the overall picture => see below at section “Components”.
b) Symmetry
Usually this one is hard to apply to B2C scenarios, so I’ll skip it here.
c) Transparency
Honestly, as I’m not a user of their service I don’t have a ultimate attitude here. However from a trust analyst point of view I just note there’s a number of people out there who think that DB failed severely in this regard. And there’s a (still pending?) complaint for injuctive relief filed to the FTC stating that Dropbox “continues to make deceptive statements to consumers regarding the extent to which it protects and encrypts their data.”
So overall this one (transparency) seems at least debatable; see also discussion on factor “Integrity” below.
d) Consistency: well, probably most of you know that three months ago DB suffered a breach which exposed all online storage lockers to anyone entering any password for ~ 4 hours.
Strictly taking the “consistency road” this does not contribute to their trustworthiness, from my humble evaluation.
e) Integrity
This post from the Hunton & Williams privacy blog provides an overview how Dropbox’ security statements (on its website) changed over time. I tend to assume the majority of users is/was not aware of those changes. In general it seems that one of their main communication channels is their blog. Which – given that most of you probably read a blogpost right now 😉 – might certainly be a valid channel… for B2C scenarios in modern times at least. Not sure if this is the right channel for the security properties of corporate information assets though.
f) Components
This is a particularly interesting one. As obvious as this may be, most users are probably not aware that DB does not operate the servers providing the service themselves. To the best of my knowledge the (Dropbox) service heavily relies on Amazon S3 and EC2 instances, in a certain setup that Mulazzani et.al., in their paper, comment on as follows: “However, the fact that encryption and storage is done at the same place seems questionable to us, as Amazon is most likely able to access decryption keys”.
g) Porosity
We can’t provide an evaluation here as we do not dispose of any information as for clear demarcation lines on the financial (e.g. who might potentially influence DB’s decisions due to simple ownership of shares ;-)) or organization/infrastructure (which 3rd parties actually provide which type of supporting service, e.g. do they share their office space with other parties in a business/office incubator etc.) sides of things.
So, once again, taking a structured approach when evaluating some party’s trustworthiness (to counter the fact that trust – by it’s very (Diego Gambetta’s) definition that we used in the initial post – is sth subjective) leads to – hopefully – interesting insight and results. Still, in this particular case, there’s another potential use of this way of looking at things: when dealing with (business’ desire to use) Dropbox in your organization, you might convert this points into a simple (one slide ;-)) checklist containing questions like
Do you know who owns the company Dropbox?
Do you know where their servers are located?
Do you know if they own the servers providing the service themselves or who else does this on their behalf? And where the servers of that “other party” are located? Which legislation applies there?
Do you know that they just suffered a breach temporarily allowing anyone in the world to access any one of its 25 million customers’ online storage lockers, simply by typing in any password?
Do you know who owns the keys necessary to decrypt data stored under your account?
[in case you like to promote your concerns the FUD way – which we do not like or recommend – you might add: “If you were a well-funded attacker, maybe from an emerging market, would Dropbox be an interesting target for you?”…]
If some people within your organization are still going to use DB for corporate data then, well, that’s an “educated decision by business” [no, no, the quotes are not put here to hint there might be a contradictio in adjecto ;-)].
Stay tuned for more stuff to come in this series & have a good week,
Enno
btw: we’ll probably have a talk about Dropbox at next year’s Troopers which takes place on 03/21 and 03/22 2012 in Heidelberg.
This again is going to be a little series of posts. Their main topic – next to the usual deviations & ranting I tend to include in blogposts 😉 – is some discussion of “trust” and putting this discussion into the context of recent events and future developments in the infosec space. The title originates from a conversation between Angus Blitter and me in a nice Thai restaurant in Zurich where we figured the consequences of the latest RSA revelations. While we both expect that – unfortunately – not much is really going to happen (surprisingly many people, including some CSOs we know, are still trying to somehow downplay this or sweep it under the carpet, shying away from the – obvious – consequences it might have to accept that for a number of environments RSA SecurID is potentially reduced to single factor auth nowadays…), the long term impact on our understanding of 3rd party (e.g. vendor) trust might be more interesting. Furthermore “Broken Trust” seems a promising title for a talk at upcoming Day-Con V… 😉
Despite (or maybe due to) being an apparently essential part of human nature and a fundamental factor of our relationships and societies there is no single, concise definition of “trust”. Quite some researchers discussing trust related topics do not define the term at all and presume some “natural language” understanding. This is even more true in papers in the area of computer science (CS) and related fields, the most prominent example being probably Ken Thompson’s ” Reflections on Trusting Trust” where no definition is provided at all. Given the character and purpose of RFCs in general and their relevance for computer networks it seems an obvious course of action to look for an RFC providing a clarification. In fact the RFC 2828 defines as follows
“Trust […] Information system usage: The extent to which someone who relies on a system can have confidence that the system meets its specifications, i.e., that the system does what it claims to do and does not perform unwanted functions.”
which is usually shortened to statements like “trust = system[s] perform[s] as expected”. We don’t like this definition for a number of reasons (outside the scope of a blogpost) and prefer the definition the Italian sociologist Diego Gambetta published in his paper “Can we trust trust?” in 1988 (and which has – while originating from another discipline – gained quite some adoption in CS) that states
“trust (or, symmetrically, distrust) is a particular level of the subjective probability with which an agent assesses that another agent or group of agents will perform a particular action, both before he can monitor such action (or independently of his capacity ever to be able to monitor it) and in a context in which it affects his own action.”
With Falcone & Castelfranchi we define control as
“a (meta) action:
a) Aimed at ascertaining whether another action has been successfully executed or if a given state of the world has been realized or maintained […]
b) aimed at dealing with the possible deviations and unforeseen events in order to positively cope with them (intervention).”
It should be noted that the term “control” is used here with a much broader sense (thus the attribute “meta” in the above definition) than in some information security standard documents (e.g. the ISO 27000 family) where control is defined as a “means of managing risk, including policies, procedures, guidelines, practices or organizational structures, which can be of administrative, technical, management, or legal nature.” [ISO27002, section 2.2]
Following Cofta’s model both, trust and control, constitute ways to build confidence which he defines as
“one’s subjective probability of expectation that a certain desired event will happen (or that the undesired one will not happen), if the course of action is believed to depend on another agent”.
[I know that this sounds quite similar to Gambetta’s definition of trust but I will skip discussing such subtleties for the moment, in this post. ;-).]
Putting the elements together & bringing the whole stuff to the infosec world
Let’s face it: in the end of the day all the efforts we as security practitioners take ultimately serve a simple goal, that is somebody (be it yourself, your boss or some CxO of your organization) reaching a point where she states “considering the relevant risks and our limited resources, we’ve done what is humanly possible”. Or just “it’s ok the way it is. I can sleep well now”.
I’m well aware that this may sound strange to some readers still believing in a “concret, concise and measurable approach to information security” but this is the reality in most organizations. And the mentioned point of “it’s ok” reflects fairly precisely the above definition of confidence (with the whole of events threatening the security of an environment being “another agent”).
Now, this state of confidence can be attained on two roads, that of “control” (applying security controls and, having done so, subsequently sleeping well) or that of “trust” (reflecting on some elements of the overall picture and then refraining from the application of certain security controls, still sleeping well).
A simple example might help to understand the difference: imagine you move to a new house in another part of the world. Your family is set to arrive one week later, so you have some days left to create an environment you consider “to be safe enough” for them.
What would you do (to reach the state of confidence)? I regularly ask this question in workshops I give and the most common answers go like “install [or check] the doors & locks”, “buy a dog”, “install an alarm system”. These are typical responses for “technology driven people” and the last one, sorry guys, is – as of my humble opinion – a particularly dull one given this is a detective/reactive type of control requiring lots of the most expensive operational resource, that is human brain (namely for follow-up on alarms = incident response). Which, btw, is the very reason why it pretty much never works in a satisfying manner, in pretty much any organization.
And yes, I understand that naming this regrettable reality is against the current vogue of “you’ll get owned anyway – uh, uh APT is around – so you need elaborate detection capabilities. just sign here for our new fancy SIEM/deep packet inspection appliance/deep inspection packet appliance/revolutionary network monitoring platform” BS.
Back to our initial topic (I announced some ranting, didn’t I? ;-)): all this stuff (doors & locks, the dog, the alarm system) follow the “control approach” and, more importantly and often overlooked, they all might require quite some operational effort (key management for the doors – don’t underestimate this, especially if you have a household full of kids 😉 -, walking the dog, tuning the alarm system & as stated above: resolving the incidents one it goes off, etc.).
Another approach – at least for some threats, to some assets – could be to find out which parties are involved in the overall picture (the neighbors, the utility providers, the legal authorities and so on) and then, maybe, deciding “in this environment we have trust in (some of) those and that’s why we don’t need the full set of potential controls”. Living in a hamlet with about 40 inhabitants, in the Bavarian country side, I can tell you that the handling of doors and locks there certainly is a different one than in most European metropolises…
Some of you might argue here “nice for you, Enno, but what’s the application in corporate information security space?”. Actually that’s an easy one. Just think about it:
– Do you encrypt the MPLS links connecting your organization’s main sites? [Most of you don’t, because “we trust our carriers”. Which can be a entirely reasonable security decision, depending on your carriers… and their partners… and the partners of their partners…]
– Do you perform full database encryption for your ERP systems hosted & operated by some outsourcing provider? [Most of you don’t, trusting that provider, which again might be a fully legitimate and reasonable approach].
– Did you ever ask the company providing essential parts of your authentication infrastructure if they kept copies of your key material and, more importantly, if they did so in a sufficiently secure way? [Most of you didn’t, relying on reputation-based trust “everybody uses them, and aren’t they the inventors of that algorithm widely used for banking transactions? and isn’t ‘the military’ using this stuff, too?” or so].
So, in short: trust is a confidence-contributing element and common security instrument in all environments and – here comes the relevant message – this is fully ok. As efficient information security work (leading to confidence) relies on both approaches: trust (where justified) and control (where needed). Alas most infosec people still have a control-driven mindset, not recognizing the value of trust. [this will have to change radically in “the age of the cloud”, more on this in a later part of this series].
Unfortunately, both approaches (trust & control) have their own respective shortcomings:
– following the control road usually leads to increased operational cost & complexity and might have severe business impact.
– trust, by it’s very nature (see the “Gambetta definition” above) is something “subjective” and thereby might not be suited to base corporate security decisions on 😉
BUT – and I’m finally getting to the main point of this post 😉 – if we could transform “subjective trust” into sth documented and justified, it might become a valuable and accepted element in an organization’s infosec governance process [and, again, this will have to happen anyway, as in the age of the cloud, the control approach is doomed. and pls don’t try to tell me the “we’ll audit our cloud providers then” story. ever tried to negotiate with $YOUR_FAVORITE_IAAS_PROVIDER on data center visits or just very basic security reporting or sth.?].
Still, then the question is: What could that those “reasons for trust” be?
Evaluating trust(worthiness) in a structured way
There are various approaches to evaluate factors that contribute to the trustworthiness of another party (called “trustee” in the following) and hence the own (the “trustor’s”) trust towards that party. For example, Cofta lists three main elements, that are (the associated questions in brackets are paraphrases by myself):
Continuity (“How long will we work together?”)
Competence (“Can $TRUSTEE provide what we expect?”)
Motivation (“What’s $TRUSTEE’s motivation?”)
We, howver, usually prefer the avenue the ISECOM uses for their Certified Trust Analyst training which is roughly laid out here. It’s based on ten trust properties, two of which are not aligned with our/Gambetta’s definition of trust and are thereby omitted (these two are “control” and “offsets”, for obvious reasons. Negotiating a compensation to be paid when the trust is broken constitutes the exact opposite of trust… it can contribute to confidence, but not to trust in the above sense). So there’s eight left and these are:
Size (“Who exactly are you going to trust?”. In quite some cases this might be an interesting question. Think of carriers partnering with others in areas of the world called “emerging markets” or just think of RSA and its shareholders. And this is why background checks are performed when you apply for a job in some agency; they want to find out who you interact with in your daily life and who/what might influence your decisions.).
Symmetry (“Do they trust us?”. This again is an interesting, yet often neglected, point. I first stumbled across this when performing an MPLS carrier evaluation back in 2007).
Transparency (“How much do we know about $TRUSTEE?”).
Consistency (“What happened in the past?”. This is the exact reason why to-be-employers ask for criminal records of the to-be-employees.).
Integrity (“[How] Do we notice if $TRUSTEE changes?”).
Value of Reward (“What do we gain by trusting?” If this one has enough weight, all the others might become irrelevant. Which is exactly the mechanism Ponzi schemes are based upon. Or your CIO’s decision “to go to the cloud within the next six months” – overlooking that the departments are already extensively using AWS, “for demo systems” only, of course 😉 – or, for that matter, her (your CIO’s decision) to virtualize highly classified systems by means of VMware products ;-). See also this post of Chris Hoff on “the CxO part in the game”.).
Components: (“Which resources does $TRUSTEE rely on?”).
Porosity (“How separated is $TRUSTEE from it’s environment?”).
Asking all these questions might either help to get a better understanding who to trust & why and thereby contribute to well-informed decision taking or might at least help to identify the areas where additional controls are needed (e.g. asking for enhanced reporting to be put into the contracts).
Applying this stuff to the RSA case
So, what does all this mean when reflecting on the RSA break-in? Why exactly is RSA’s trustworthiness potentially so heavily damaged?
As a little exercise, let’s just pick some of the above questions and try to figure the respective responses. Like I did in this post three days after RSA filed the 8-K report I will leave potential conclusions to the valued reader…
Here we go:
“Size”, so who exactly are you trusting when trusting “RSA, The Security Division of EMC”? Honestly, I do not know much about RSA’s share- and stakeholders. Still, even though not regarding myself as particularly prone to conspiracy theories, I think that Sachar Paulus, the Ex-CSO of SAP and now a professor for Corporate Security and Riskmanagement at the University of Applied Sciences Brandenburg, made some interesting observations in this blogpost.
“Symmetry” (do they trust us?): everybody who had the dubious pleasure to participate in one of those – hilarious – conference calls RSA held with large customers after the initial announcement in late March, going like
“no customer data was compromised.”
“what do you mean, do you mean no seed files where compromised?”
“as we stated, no customer data, that is PII was compromised.”
“So what about the seeds?”
“as we just said, no customer data was compromised.”
“and what about the seeds?”
“we can’t comment on this further due to the ongoing investigation. but we can assure you no customer data was compromised.”
might think of an answer on his/her own…
“Transparency”: well, see above. One might add: “did they ever tell you they kept a copy of your seed files?” but, hey, you never asked them, did you? I mean, even the (US …) defense contractors use this stuff, so why should one have asked such silly questions…
“Integrity”, which the ISECOM defines as “the amount and timely notice of change within the target”. Well… do I really have to comment on “the amount [of information]” and “timely notice” RSA delivered in the last weeks & months? Some people assume we might never have known of the break-in if they’d not been obliged to file a 8-K form (as standard breach-laws might not have kicked in, given – remember – “no customer data was exposed”…) and there’s speculation we might never have known that actually the seeds were compromised if the Lockheed Martin break-in hadn’t happened. I mean, most of us were pretty sure it _was_ about the seed files, but of course, it’s easy to say so in hindsight 😉
“Components” and “porosity”: see above.
Conclusions
If you have been wondering “why do my guts tell me we shouldn’t trust these guys anymore?” this post might serve as a little contribution to answering this question in a structured way. Furthermore the intent was to provide some introduction to the wonderful world of trust, control and confidence and its application in the infosec world. Stay tuned for more stuff to come in this series.
Have a great sunday everybody, thanks
Two days ago I gave the keynote at an industry event, reflecting on the changing role of traditional security controls in the age of virtualization and the cloud. As this was an updated version of the stuff distributed in the conference proceedings, some people have asked for it. Voilà, here we go.