March 29, 2017
Go-To-Market And Category Design Fundamentals
In this Heavybit talk, Jennifer Johnson shares a methodical approach for developing a go-to-market strategy. She covers category design fund...
Building on a major cloud provider’s platform doesn’t make you secure. In this session, security leaders from Cisco, HashiCorp and Cisco Meraki join moderator Ody Lupescu to cover the core tenets of modern cloud infrastructure security, including robust identity and access management, maintaining application security in multi- and shared-cloud environments, and data security at rest, in transit, and in backups.
Ody Lupescu: Hello, everyone. My name is Ody and I will be moderating today’s discussion. For a day job, I look after security at a company called Ethos. It is a startup, a series C startup for that matter, and I deal with a lot of the things that we’ll be discussing on a daily basis. I’m joined here by three peers. I would let them introduce themselves, and I will also ask them to mention a fun fact about themselves. Something that shows that in their daily lives they’re not all about control. So, Marzena?
Marzena Fuller: Marzena Fuller, I am the chief security officer at SignalFX. (Ed. Note: Since the conference Marzena has moved to Cisco). I lead the entire security practice, from application security to infrastructure security, compliance and privacy. A fun fact, I’ve recently picked up my high school hobby, which was painting. I’m lucky to live right on the water and when I have time I paint what I see outside, which is mostly container ships and port of Oakland.
Talha Tariq: Sure. My name is Talha, I’m the chief security officer at HashiCorp, previously at Microsoft and BWC. A fun fact about me, I’m a photographer, and I like to disagree with Ody on stage.
Ody: We’ll get a little bit into that today, you’ll see. Lastly?
Daed Latrope: Hi, I’m Daed Latrope. I run security for Cisco Meraki, and I didn’t come up with a fun fact. I sew, I made two of the things I’m wearing right now.
Ody: Very cool. Very nice. Thanks to everyone, and now the topic today is everyone’s favorite topic, cloud security. How do we go about it? As we tailor our discussion today, I’m trying to basically make sure we straddle the right line between going in the weeds in the technical details, or staying a little bit at high level. We’ll try to do that.
The first question, cloud security or cloud infrastructure security. Because we’ll focus on infrastructure primarily, and not the typical SaaS applications. It means a lot of things to a lot of people, so what does it mean to you? What are the buckets that you consider to be part of the cloud security? Maybe we start with you, Marzena.
Marzena: Definitely. When I think about cloud infrastructure security, it’s AWS, it’s GCP, it’s Azure. In order to be successful with establishing best practices, first of all you need to understand what is the shared responsibility model. Which means, “What are the providers responsible for and vis-a-vis what are you responsible for?” That’s number one for my experience.
Number two is having a comprehensive identity and access management strategy because of the advantages of cloud, because you can deploy resources quickly, because you can scale resources quickly. That also means that there’s a lot of risk associated with that speed and wide access, and you need to be able to limit that in an appropriate way. Lastly, a comprehensive monitoring strategy.
For example, AWS provides you with all of the resources like cloud trail, and you can trace all of the API calls but you have to be able to capture that data and extract meaningful and actionable insight. Only then you are able to have full visibility and control over your infrastructure.
Ody: If I understand correctly, understand exactly what the cloud provides you and what you’re responsible for? If the cloud is a pile of wood, it’s up to you to design and to use the wood to build something that will withstand whatever you’re trying to do? Secondly was understanding the identity and access managing that, and thirdly is gaining visibility?
Ody: Talha, do you have–?
Talha: Yeah, I think there are various ways to slice and dice cloud. You have your three major public cloud providers, but a lot of on prem infrastructure is also a private cloud. HashiCorp tends to see cloud as a very [cloud agnostic way]. I think what’s really important is generally speaking your cloud is composed of different layers and compute network storage, and then a bunch of services that glue all these things together. Different cloud providers have different services, and what’s really important to Marzena’s point is to understand, one, what security responsibility the provider is taking care of and what is your responsibility. Then around those responsibilities, what are the applications and services and tools that you have to gain visibility, to control access, to protect your data.
Ody: If you set up your– When you set up your cloud environment, you have two main buckets for me. One is a control panel and one is the workload, and they each have independently the same type of controls. Is that your take as well?
Talha: I think going each product, service or organization will think through some of these things differently, and it’s very context specific in what your application and service is and how you think through the security requirements. Again, in the context of the product and services you’re looking at, there’s a bunch of security controls that come out of the box that you leverage. [inaudible] s one of them, access control is one of them, [inaudible] is one of them and monitoring is one of them. But then you also have to think through how you protect your business and what other fraud or abuse cases that you need to worry about, and how you communicate trust in your product and service. I think it’s a spectrum of things and there’s no one answer that fits everybody.
Ody: Got it. Same topic, what are the categories? The buckets?
Daed: Yeah. I don’t think there’s anything special about cloud, with everything you need to focus on preventing as many mistakes as possible and noticing when things have gone wrong when prevention has failed, and then having a clean response at the end.
Depending on your maturity you might have a really basic answer to each of those, but you should have thought through them at least like a baseline level as you’re setting things up. To your earlier question about “How do you think about the control plane versus your workload?”
Some of the basics that small companies fall down on are things as simple as making sure your root account is set up the right way to prevent takeovers. I would definitely run through those simpler things first to lay a foundation before you even start worrying about the inbuilt security tools, which are absolutely something you should take advantage of.
That’s possibly the main benefit of going public cloud is that you get to stand on the shoulders of giants. You don’t have to reinvent the wheel, you don’t have to come up with all of your own vendor vetting. There’s just a lot of stuff already built in.
Ody: Thank you. That was kind of the point, that before you start building a workload you better set up the control panel. You better go in there and envision the longer term model, “This is how I plan to manage this environment.” If you start with the workload and then go try to make the control panel work, that may require some revisiting.
Talha: I think I understand your question better now, and I think the best analogy I can give you is I like to think in terms of trust boundaries. Your trust boundary and your threat profile of external facing service is pretty different from something which is internal facing, so what kind of security boundaries and controls you’re going to implement for each layer of these trust boundaries is super important.
Ody: Got it. That drives the next point. You’re a startup and you have limited resources, you’re building a product which is the main thing you’re trying to do. Now you’ve basically got to prioritize, how do you go about prioritizing what you do from a security perspective in the cloud? We talked about the control panel and setting it up right in the first place. That takes a little bit of time, but there’s some things that you should do and something that maybe you can punt. What is your take on? What should you do? What’s the first thing you would do? How do you prioritize?
Marzena: As a CEO, the first thing you should think about when you think about security is hiring an experienced technical leader who will help you to understand what are the priorities and how we should address them. The reason this is important is that security is table stakes right now for a lot of companies, especially when you are early stage or a mid stage startup it’s important to number one, limit your risk exposure. And number to, baking security in every single process that you have in place and make it a true core tenet of your company.
Ody: Marzena, just because I’m argumentative. I was going to say that if I’m a six person company I’m just not going to hire a security person at that point. Maybe you still need to do something, something to secure this environment. Because look, I’m starting to build a product and I have some code, and I’m going to say “I want to do a proof of concept. I want to show people what I built.” Without hiring someone, what’s your take on how you would approach this?
Marzena: Two things. It’s ownership and it’s subject matter expertise. If you don’t have a dedicated person who has the ownership of a security program then you have to instill that ownership in your engineering leadership and in senior engineers, so that number one, they are responsible for security. That very closely ties into the DevSecOps model where engineering groups are responsible for security, the same way they’re responsible for reliability. That is a big part of that, and then providing them with resources to be able to learn. Because not everybody’s a subject matter expert in security, but if you’re a good engineer you can learn very easy and trust the engineering concepts and the security concepts.
Ody: Got it. Talha, if I can go in the same line. You’re setting up your first [inaudible]. You’ve got an idea, you’ve got a product. What do you do? The first thing is we talked a little bit about the control plane, but how do you approach that? What were the first couple of things that you would prioritize in setting up the controlled plane, setting up your first workloads?
Talha: I’ll answer first on how you should think about building a security program, and if you are founding a company, especially for founders in the room. If you’re a two people startup or a ten people startup, and you may not think to act at a certain stage to bring in a full time security person, talk to your advisers and talk to your VCs. They’re very well connected. Talk to your peers, go reach out in the security community. Oren talked about the framework, the open source, which is Security4Startups. It’s very well laid out in terms of security controls, which are expected for seed companies series A companies, series B companies.
There is knowledge material out there, there is plenty of expertise out there. You can bring in somebody as an advisor just like you bring in legal expertise or finance expertise. Even though you may not hire a CFO [inaudible], but you will go talk to a finance professional human or have a general counsel. But you go out to a legal professional. Security is not any different if you think about what do you build when. I think that’s basically where you start, and at a certain scale you might want to bring in full time security people.
In that case, what Marzena was referring to, bring in a leader first who can thing through based on where the company is going a year to a year in advance of what else is coming. What security, privacy and regulatory compliance requirements you would need to adhere to and how should you think about building a strategy in the program. That’s one, and I think in terms of what you should do I’d say in security a lot of security is about risk management.
There’s no perfect security, and you address security controls based on the environment you’re operating in and the service you are selling and what your threat profile is. Unfortunately, the industry’s really bad at threat modeling, and individuals are also really bad at threat modeling.
But I think a very simple start is just going through what are the top five things that will go wrong depending on what service you’re selling? Even if you were Uber, “OK. What are the prevailing threats around selling something that’s Uber?” If you are dealing with a large amount of PII, how should you think about risks to PII?
If you’re operating in that regulatory environment, what kind of risks do you need to adhere to? If you are selling a fintech service, what is your core asset you’re protecting? Understanding the threat model is super important to figure out what your security program needs to do, and what you should protect and how you should protect, and how you should think through building the security program.
Ody: OK, so I have to say that I’m looking for a more specific answer. Because so far I have been very general, but regardless of the threat– That will be a choice, but let me explain what I have in mind. When you set up something, at the end of the day, yes you’ve got the risk and there’s going to be a workload. There’s going to be your application, the way you build your service or your application, but you also have this cloud provider that gives you this framework to build something with. So it’s like, can somebody give you a bunch of– I don’t know. Whatever, cement, bricks, and you’re trying to build a house.
What should you be mindful of when you build this house? What are the first things. Yes, you should have a blueprint and so forth. But practically, what would be the things that you’re very likely to regret later on if you don’t do initially when you’re setting up cloud?
Daed: The way I think about this is trying to lay a strong foundation of the things that would be very, very painful to change if you don’t do them right up front. There are a lot of things that you can do later and it’s not terribly different. If you get a pen test too early, it’s not going to be very meaningful for your organization, so the things I think about are patching and building it to change.
Visibility, knowing what’s happening in your environment and what you have. Both of those are going to serve a variety of needs for you in terms of reliability and development and speed, and they’re also just– It’s impossible to build a good security program without those two things being met. If you don’t know what you have in your environment, if you aren’t able to apply patches, it doesn’t matter how good your security program is or what bugs you’re finding because you’re not going to be able to close those holes.
Ody: Got it. From my perspective, oftentimes the first thing you do when you set up an environment is you’re going to give access to everyone to whatever account you’re going to have. Maybe the few things you could do is set up a couple of different environments, set up a production separate from development and just buy some single sign on licenses, and then integrate with a single sign on provider.
Set yourself up in a way that you don’t have to do the clean up later. I think the security framework for startups, not that we’re going to talk too much about it, but that gives you some idea of what we’ve seen as things that eventually, if you don’t do, they’ll require a lot of clean up later.
Talha: I think if I had to choose one, for me it would be access control. You provision access to people, you provision access to machines, things talk to each other and people talk to each other. It’s about access, and it’s probably the number one area that a lot of companies fear. That security gap just keeps on growing if you don’t handle it day one.
Marzena: MFA everywhere.
Ody: Exactly, MFA everywhere. The other thing is if you create private versus public subnets or VPCs, just make sure you don’t put things in the wrong place. It’s not easy to move it at a later point in time. Again, take a look at the framework and you may see a few of these recommendations. Now going back to our agenda, one of the good things about the cloud providers is they give you a lot of things. When you build a house, they give you the electrical wires and everything so you can build. But oftentimes the wire only works in that particular environment, so you get locked in.
For instance, you use AWS KMS you’re stuck with AWS. You can move to Google, but it’s going to be a little painful. So, how do you avoid that? What what’s the pros and cons for doing this? Daed, maybe we start with you.
Daed: We’re starting with me because I have the contrarian view on this. I don’t think it’s worth worrying about when you’re a smaller company. The whole point of being on these cloud providers is that you can make use of all of the extensive functionality they offer, and getting off of them and diversifying is a later problem.
Ody: I think, Talha, HashiCorp has the vault where you can use vault and you can use it in AWS or you can use it anywhere. Why would anyone start with KMS versus doing–? What’s your take about being locked-in and about having the flexibility?
Talha: I think that there are two ways to think about the problem. The problem number one is, build vs. buy vs. use decision, and you should build what is your core differentiator and your core product and not worry about doing the same work, which is a small problem. Especially if it’s not your core secret sauce, and that draws decision of which cloud provider to go to and “What’s a commodity service, and what you should just leverage out of the box.
Whether it’s Google or Amazon or GCP or if you are in some other markets, some other cloud. That’s typically how you drive their decision, and in terms of which tool to use, which [inaudible] to use, which identity platform to use, I think you have to think about if eventually– Your product doesn’t, even if you are cloud native, even if you build everything in AWS you will always have integrations with other SaaS platforms and other tools, other integrations, other applications which are not on AWS.
We tend to think of these as workflow problems, like secrets management is a workflow problem. You may have application X sitting outside of AWS talking to some infrastructure middleware sitting inside AWS. So the more you start hooking– Each cloud service has their own maturation of not every service is a tier one service, some of them are experimentation services. But if you are merging cloud, if you’re talking to various things, we tend to see these as workflow problems and that’s where we [inaudible].
Ody: If I understand correctly, know your capabilities and optimize for whatever you’re trying to achieve in your capabilities. And yes, being locked in the cloud is not going to be the end of the world. In some cases it makes sense and in some cases it doesn’t, so again, lots of homework and no single answer. Going on to the next topic we won’t start with Talha, even though his company has a stake in this and a big one too, but we’ll start with Marzena. Let’s talk about infrastructure as code, the idea being if you’re going to build something in a cloud or more than one, you can start a number of ways. You can go to a console, set up some things, you can set up the workflows manually through a CLI and so forth.
But you can also do it through code, and what happens if you try it from the beginning to build it to code? Because if you do it through code, say TerraForm, essentially everything that you do from that point on can be managed through code. What’s your take on this? Is this something some company should start from an early stage?
Marzena: I would say absolutely. It’s not an infrastructure as a code, but also security as a code would play very nicely there. Where you can define all of that configurations, be that for infrastructure or for your security. We can account and truly enable your engineering teams to be part of that DevSecOps model.
From my experience, that is really the only model that security can scale. Because as the company is growing from 100 people to 500 people, you will not be able to hire sufficient number of security engineers to keep up with that demand.
But you will have a much easier job on your hands if you incorporate those practices in your code, and then if your engineering team is partly in ownership there.
Ody: All right. Daed, do you concur that is worth taking the time? Perhaps it’s a little more comfortable if you don’t have the experience, should just some founder take time and get themselves familiar with doing infrastructure as code?
Daed: I think it’s more important if you don’t have the experience, because you’re much more likely to accidentally make a rookie mistake and blow away a customer instance, and then have a very bad day.
Ody: From my experience, I’ve been in two companies now. One that did not follow infrastructure as code and there was a massive amount of cleanup. Then later on the attempt was to do that and use TerraForm. In my current environment. We’re trying to build everything from scratch with TerraForm, and have the ability to manage, recreate and take care of it. I think obviously HashiCorp is a big player in this space. What’s your take? To what extent do you believe this should be the one must do?
Talha: I think it’s just there’s a market is pulling us in that direction, as well as if you see the growth of the cloud players as well as the entities which are moving to the cloud, and open source adoption and programmable infrastructure. That’s clearly where we play in, and I think there are tons of benefits of using infrastructure risk or programmer infrastructure because you could label them and version them, think through their dependencies much more clearly. If you look on GitHub, HashiCorp configuration languages are the number top three, if I’m not wrong, in terms of the programming language that is getting the most adoption. One, there are tons of benefits going through that.
But two, I think from a cloud security perspective, it’s also way easier to rationalize more security and policy controls we should have. We tend to think of policy as core as a framework where once you have dozens of developers collaborating on what your infrastructure should look like, you’re secure. It’s very hard for security issues to catch up on infrastructure issues, configuration issues, how to think about security. What they can do is just start earning very simple qualities, like “OK. My policy says you should not have root without an MFA on.
My policy says you should not have external security gropes allowing traffic. You could just add one or two lines of policies, and then your infrastructure code honors those policies. It also helps reduce the blast radius significantly, as your teams grow they’re working on specific areas. Some might be service focused, infrastructure focused, middleware focused. Then you can separate out those concerns and look at chunks of infrastructure more cleanly.
Ody: I think Sentinel in the case of TerraForm is a great option if you’re going to use TerraForm, use Sentinel and build some guardrails. The other thing that enables you too, I think, is the self-service. By creating this specific framework you can allow people to self service themselves and not expose yourself to an unknown amount of risk.
All right, now the next topic is slightly different. We’re going to talk about remote access. It’s slightly different, but it’s related. Say you build this stuff, this environment in one or more cloud environments. You’ve got to manage it. How do you do that? Because all of a sudden you’ve got a CLI that can be used from anywhere. You’ve got the console that unless you put some pretty smart solution, anyone can access it from anywhere. Then you’ve got your workloads that you need to get to, and the question is “Do you really need to get to the workloads? That’s the other question. Can you build them so you don’t have to get there?
There is all answerable code and it’s all TerraForm, it’s all orchestrated. But let’s say you’re not there yet, so you build stuff and you still need to get to it. How do you do that in a way that straddles both safety, productivity and ease of use? Daed, do you want to chime in on this?
Daed: There’s a little bit of a hit to productivity, but I still think the earlier you can tolerate having a jump host in place so that you’re not just having people connect from their home networks and all these other places, it’s really going to benefit you. Getting that auditing in place, having confidence that all of your data isn’t going to just walk out the door really helps.
Ody: Would you think that that’s one of the first things you should do as you build your workload?
Daed: No, for sure. But I would say by the time you have live customers in your environment, it’s something you should be thinking about.
Ody: Going down this line, is it too late at that point to say if you have an SSH and you allowed SSH in your environment, and you’ve had it for a couple of months or maybe six months before you actually have a customer. Is that too much of a risk, do you think? Or do you think the watershed moment is when you have a client?
Daed: The correct time to make a security change is always yesterday, so no matter when you’re looking at it, then I think it still makes sense.
Ody: Got it. Marzena, what’s your take?
Marzena: It’s based on my experience, there are a couple of things that are very important to do first. Zero trust security is a concept that is getting a lot of traction, and when you really look beyond the word itself “What does it mean? ” How to implement that is being able to ensure that your access is being grabbed at based on risk, like what IP address you’re coming from and if your behavior is matching the previous behavior patterns. Being able to identify in provision access dynamically to the users and revoke it when the behavior is not what is expected. That’s one element.
The other one is providing logging of what is actually happening when your engineers are accessing that environment. They do have SSH access to the instances, or they do have access to production data via front end. Which is sometimes necessary to provide support, but being able to have those logs for your own use and for customers use is critical for your visibility.
Lastly, you look at what are the trends? What are we supposed to be doing with SSH? SSH cert is something that I like a lot where your access is ephemeral and can be revoked and can be tied to a specific IP address.
Ody: It sounds like everyone is saying “Do something, don’t just allow free access to your environment without any type of management at all.” Now going back to infrastructure as code, because it’s not just infrastructure. Now it’s the management of the systems, so do you see really a need? If somebody was building something from scratch, how often do you see a need for people to actually get to the workload to actually direct connections? Versus using the same CI/CD to manage their changes to the systems?
Talha: I think there’s definitely a need, because even if you’re doing infrastructure as code it’s a static piece of code which is not running your applications yet. A lot of interesting issues you’ll find in production when you have real data or real customers, real applications, scale issues, performance issues. There’s obviously a need for debugging and things of those nature.
Ody: Why not just take the logs? The one thing is you can take the logs and put them somewhere.
Talha: Look, I tend to see these things as crawl, walk, run. If you start putting in too much security when you are a two people or ten people company, what do humans do? They’ll avoid the gates that you put in and they’ll just take the shortcut or the most efficient, easy way possible. But I also think there is value in thinking about what kind of service you’re offering.
If you’re offering a security service the bar is high, right? You should absolutely think about who has access, when do they need access, why do they need privileged access and how do you think through the accountability and auditability aspect of it? And how can you rationalize why that privilege access is needed every day, every month, every week? There are patterns that you can think through to avoid this problem, to become a big problem in the first place.
Ody: Got it. So if I was to summarize, do something about it from the beginning. In other words, set up a VPN service or use a
VPN service. Most of the cloud provider give you some capability similar to a VPN that secures the access to your workloads.
Try to restrict access to your consoles as much as possible. It’s a lot more complicated to restrict access to particular devices and so forth, but try to do something about this remote access from the beginning–
Talha: I think the — Sorry, the security problems of 10 people companies are very different than security problems of somebody like Netflix. At that scale you have very different problems of automation, of access. When you are a ten people company there are very simple things you can do. Document the five people that need privileged access, think through only provisioning just in time access, and not having a blanket admin shared by ten people all the time.
Ody: I think you’re setting a precedent. Think about the things you do and you’re setting precedent. If the culture becomes that everyone gets VPN access and you’ve reached 30-40 people, then that will be the expectation. It’s going to be harder to go and take it away or change it at that point, but bottom line is try to do something. This is important. All right, going to the
next topic. Let’s talk a little about encryption, cloud encryption.
We talked a little bit about KMS here, but KMS may be one piece of that puzzle. Suppose you have workload, you just find an application and say you’re a company that’s going to do something for a client, and their client is giving you their API keys to their Google account. They’re going to say, “Yes. You’re going to provide a service for me, I’m going to give you my –” The client says “Fine. You want my API keys, what are you going to do with them and how are you going to encrypt them? And then how?” How do you approach this, what’s your take? How do you approach it in the cloud environment, and what’s the pros and cons? Talha, maybe we start with you.
Talha: With me? OK. The first question you need to ask is what problem you’re trying to solve, then oftentimes the use of KMS or some encryption tool is actually an access control problem. You are trying to prevent paying through access and authorization to some piece of data, and you could encrypt that data but then you have to decrypt for someone to have access to it. Then again, it becomes an access control problem, not an encryption problem.
If you separate out the use cases for when you need access control and when you need data protection, those things drive what kind of security and data encryption and key management system that you need.
Ody: That’s right. In a way, it is key management or access control because your workloads need access to this data. You’ve got to build in this whole capability. But then, is it really– As you approach it, let’s talk about a specific example. Should you encrypt your S3 buckets if your policy says that all your systems can decrypt the S3 buckets? How much is that going to buy for you?
Talha: There’s security controls, and they tend to cater to either risk reduction or meeting some compliance obligations. Some of the compliance standards were written in pre cloud, where HIPAAs and HYDRAs and PCIs are infrastructure technology agnostic, so oftentimes you may have to do an encryption to meet a specific regulatory environment. Oftentimes you do encryption for security and data protection.
Ody: Got it. All right, so Daed maybe we’ll go to you and ask you what’s your view on encryption in the cloud?
Daed: I mean, honestly, for a young company I think about meeting the basics. Don’t go crazy trying to implement vault if you’re not there yet, but do at least do field-level encryption and make sure your disks are encrypted. Disk encryption also being one of those things, by the way, that’s painful to change later on. If you don’t start there then having to do that migration is often slow and costly.
Ody: So you think of UBS volume encryption? To what extent do you think doing encryption for the sake of satisfying customers? For instance, I’m going to have a client that’s likely going to ask me that. Do you think it’s worth doing it? Even though it’s like painting the window sills? Do you think it’s worth doing it from day one?
Daed: I do. When you’re looking at you’ve had some relatively basic breach and now somebody has a dump of your passwords, you’re having a very different conversation with your customers if they have to decrypt all of those or brute force them than if they’re just sitting in plaintext. That’s very embarrassing for your business.
Ody: I think, Marzena, you will be closing on this. What’s your take?
Marzena: First of all, you have to understand your threat exposure and why you are encrypting that data as Talha mentioned. When customers ask you “Is your data encrypted?” What does it really mean? Are you talking about disk encryption? Are you talking about the field-level encryption? Just understanding why you want to do that and how you read those saying your risk exposure is critical, and that you can decide how are you going to implement that.
Using KMS is very useful because then you don’t have to worry about the lifecycle management of your keys, which quite often is completely not addressed by a lot of early stage companies.
Ody: So the message is de-leverage encryption when necessary, if you can build it in without creating a significant overhead just to satisfy potential requirements from your clients, it’s worth doing it. With KMS, also be careful the way you set it up. It’s all in IM, it’s based in and tied in with your access control, so it is an access control problem at that point. That’s all we have time for today, but I wanted to thank all of you for this.