January 26, 2016
Ep. #12, Payment Strategies for Developers
In this episode Edith and Paul talk about the clash in OSS between developers looking to get paid and software companies looking for things ...
First, I always like to start off alittle bit to figure out the audience and what you guys are up to and want to get out of the presentation like this.I have a smaller group tonight, so I am cool with yell out questions, hold them to the end, whatever you want to do. We can kind of go however you want.
This is a bit about my background. I recently founded a security company, spent about a decade plus in security. I started in reverse engineering working for the government developing exploits back in the mid-to-late 90s. I went on to publish some papers and books and random things on the corporate side and ran security at Disney for a couple of different visions, then TiVo. Then James and team recruited me into Heroku and Salesforce, and then I left and started my own company.
This is pretty much what I live every day and I know the challenges of trying to figure out building security and what do you do and when do you do it and how do you do it, and that it's a pain in the ass and do you really want to spend money and time on it. I get that because I've been yelled at for many years by all the people around me telling me that security's a pain in the ass. We're going to try to get away from that and talk about exactly what's relevant for you guys and how you can start and figure out where you're at and where you should go.
To kind of just level set a little bit, anybody want to share a little bit about what they're hoping to get out of this today or where you might be at security or some of the blockers or questions? Or are we going to be a shy crowd? Ok go ahead.
Q: What do we need to do to get enterprise customers using our products in terms of security?
A: What you need to do to get enterprise customers to use your product from a security standpoint. That's normally the biggest one.
People for some reason want to get enterprise customers and make money. Somehow security plays into that, which is great because all my life everybody said security has no ROI, why do it?
And I've always said well, because at some point you're going to have to do this and have to show what you're doing.
I'm going to start off with some very basic things. If this goes too basic, yell at me and tell me. Say move on. If you guys want to dive deeper, yell at me and tell me. We can go all the way into stuff. This is what literally I do all day long and I have some of the most amazing security people in the world yelling at me every day to tell them more.
This is a very simple thing that in most cases I would be embarrassed to ever admit that I will actually reference. It's what we call the CIA Triad. You can figure out why it's called CIA on there. This is the principles to all security. If you can keep these three things in mind at all times then you'll have some guiding principles that will set you down the right path. Not necessarily how to do certain things, but this is what all security people think about. They think about the confidentiality of data.
If you have enterprise data or if you have PII from your customers, keeping that private. Even Facebook has to keep some of my stuff private. I share some things, but I send messages to my friends and tell them they're dumbasses or ask girls for inappropriate photos, whatever it might be. I don't want that to be public, so that's where that comes in.
Integrity. Obviously enterprises want to make sure that the data that you're storing, that their data is actually what it's supposed to be. That somebody didn't modify it, didn't change their sales numbers, that their billing statements didn't get changed or usage statements didn't get changed, whatever it might be. They want to make sure that that data is of quality because that's what it really comes down to.
Then availability. The reason availability was actually added to this years ago and it became a triad instead of just two principles, was because security people forgot about this part.Security people thought, oh if I lock it all down, then it's secure. They actually forgot that somebody actually had to get to data to do things with it.
This is where most security programs and implementations fail, is that they are too rigid and they become too difficult and then that's why you have security programs that are just a pain in the ass.
How many of you ever worked for a big company? A Fortune 5 or something like that. Did you like the security people there? No, of course because it was a pain in the ass and that's where we all failed. Do you like any security people? Yes, good answer because I'm here. Alright, perfect.
Before we kind of jump in a little bit more. First thing to say is "security." I tend to put it in quotes a lot of times. I'm going to do the douchey-like airbag quotes real quick. Security really doesn't mean anything. It's compromised in many things. You have your technical pieces, you have your management pieces, your processes, you have the sales side, the assurance, all that kind of stuff. And depending where you are in a company depends on what you really have to try to tackle.
Are most companies here some kind of SAS web-based platform? Okay, so you know all this. James just hooked me up with somebody the other day, the Lockitron guys. Honestly a very different model. Iwas like, "Yes I want to talk to these guys about their security." Then of course, all the reverse engineers that I employ were like, "No we want your lock."That's what they were really interested in.
Anyway, so you have all your different kinds of pieces of security. The technical bits are usually what most people ask about. This is where most people start because this is what you're going to be drilled about from the enterprises most often. Enterprise security guys, they're going to come to you and they're going to say, "Oh you want our money? Okay, what are you doing about all of these things?"
They're going to send you that stupid questionnaire in Excel that's like 300, 400 questions long with like six tabs, it's all color-coded and everything. Andsome risk analyst on the other end takes the thing and inputs all the data in some big system and they tell you how secure you are.That's not really what happens. That whole thing is meant to just scare you and basically say, "What are you doing, are you doing anything?" I can speak from firsthand because I used to send that to a lot of people. I still do every now and then to piss off a couple of my vendors. I will send that out.
Really what people care about is they're going to look at this and if they're a technical security review, these are the top things that they're going to ask about. They're going to ask about code quality. They're going to ask about logging. They're going to ask about access controls. They're going to ask about your patching and updating. And what they're saying is, "You don't have to be perfect, but what do you actually do?" If you can give them an answer.
If you can show them something, that puts you above most other people that they're talking to. That puts you above most other vendors. It's all about just removing a little bit of that fear.
The technical piece, this is the one that most people have the biggest hurdle withbecause it's so expansive. There's just so much going on because I have a whole other slide for technical. Now you have infrastructure. So all of your servers â€” are you running on Heroku, are you running on your own data center, your own EC2, what are you doing? It just kind of continues and people want to see that all these little boxes are checked and that you're doing something in every one of these areas.
Once you kind of get past that, and you say well, there's these technical bits and there's this process and there's all of these things, there's this list of things that you can do under security, it really breaks down to minimizing risk. But it's minimizing risk both for your customer, be it end user Joe in Omaha, or a big Fortune 500 company. But it all comes down to minimizing risk and making sure that what you're doing is the right thing, and that you can show that to your customers. That assurance, that whole transparency of security is another big takeaway that you should take away from tonight, if nothing else.
Define what you're doing and be open about it to your customers. They will appreciate that.
If you go look at like Saleforce's site, I love Salesforce as an example of this. They have trust.salesforce.com. It's a whole site dedicated to how they handle your data, how they handle their security, and it's a place for you to start that conversation with them. Salesforce blew open the SAS world for all of us. I was at a SAS company, back before it was called SAS many years ago, before I was even at Disney, and security was this big thing we always had a problem with. We hadn't caught on, or I should say I hadn't caught on, to the whole be transparent. I was very reluctant to talk about my security.
Salesforce, they said nope we're going to be transparent, and they have blown it open to where people will actually trust cloud solutions now, and it's all because of that transparency.If you take nothing else away from tonight, remember that one thing and that will help you.
Alright, so the "why" of security. We heard one thing, it was about getting enterprise business. Most security people will give you that top answer. They're going to give you the bullshit answer of why you should do security. Because without security, your business is not going to exist anymore. You're going to lose so much business, you're going to lose so much revenue, damage to your brand, all of this.
When I started at Disney, I called up brand management. This is a super-large company. They have an entire team just brand managementand there's like 300 people on that team.I got this very nice lady, and I said,"Hey,ifone of our web applications, one of our websites,"and we're talking disney.com, ESPN, ABC, I said, "if that gets compromised, what's the impact to the brand of Disney?"
This very nice, sweet lady down in LA, started laughing at me, and she literally said, "Adam, it is not even relevant. The security of that and if somebody breaks into ESPN.com, will not hurt our bottom line whatsoever." She's like, "We have people with heart attacks in the park. That should hurt us, and it still doesn't." She goes, "How many people have died in our park?"
And I said, "I don't know how many?"
She goes, "Zero."
And I go, "Well why?"
"Because we don't allow them to pronounce the person dead until they get to the hospital, so technically they died at the hospital."
I was like, "You're evil.That's a whole other level, but okay point taken. You don't care."
So, I had to go down some whole other path to figure it out. Now, the one thing I will say is, this was early onand Disney was still very focused on their parks and resorts and their physical business, the one thing that can hurt Disney: One day I got a call. I have no idea to this day how this lady got routed to my desk. But I got a call, there was a lady screaming about her kid got a spam email for Viagra.
She's like, "My kid has only ever signed up for your game," it was Club Penguin or something like that, "and you got compromised and now my kid's getting Viagra spam and it's talking about penis and talking about this and that."And I'm like, "Oh God."
You've never had to deal with a nightmare, if you've not had to deal with an irate mother. I will take any internet attacker on the planet. Script kiddies, DoS in my site, great. Somebody wants to steal some data, great. I never want to deal with an angry mother ever again in my life. This woman would not stop calling me for a month. Turned out it was not Disney. Her kid had actually signed up for something else and that's where it came from, but I had to deal with that.
Anyway, that's what you're normally going to getand that's what your customers will try to tell you, and they'll try to tout it. It's not right. In the security industry we've always tried to hold to that.TJX was the largest credit card compromise in history at the time. Since then there's been two larger. Year-over-year revenues at TJX were up the year following this massive credit card theft. Only one company, only one sizable company, has ever gone out of business because of a compromise. That's it, one. So that's not why.
The more crappy answer is: why you do security depends on your business. I actually started to write that in this slideand that's why I wrote the crappy answer. Because I just felt crappy saying, "You know what, I don't know what all you guys do, but it depends on your business, that's why you're going to do security." I felt like that was a shitty answer, so I wasn't going to leave you with that.
The real answers. One, because Spike Lee told us to do the right thing. I don't know if you guys have seen the movie from 1989. It's a little old. I'm dating myself all of a sudden here.
Really, it's about protecting your IP. You have IP that's valuable. Your company, you want to go get new customers, you want to go IPO, you want to get acquired, whatever it is. That's intellectual property. If that gets out there and gets lost, you have nothing. The value in your company is gone.
I know a very large company that we work with, they make everything from some household appliances to bombs, literally. This company, in the last quarter, has been beat to market six times by Chinese companieswith their own schematics. Their exact product design. They've been compromised for at least a year we know at this point, and they're losing market share and they're losing revenue. They can't do anything with that. The product's already out there, they're just a me-too player and that's it.
Even more importantly for small companies though, is the IP of your customers. So if you want to get a large enterprise customer,enterprise customer has maybe data on their employees, on their customers, other intellectual property and business data. The right thing to do is protect thatbecause they are entrusting you with it. And also, let's be honest, none of us that run startups can sustain a lawsuit from Disney for liability.
There's that whole financial side of it as well. I see many small startups really go into bad shape because they had to pay out a million to 10 million dollar liability claim against a big enterprise because they signed a contract that was a little too loose.
Take that for a warning as well. Be careful with your contracts when you talk to big enterprisesbecause they will try to get whatever they want and you want their money, so often we sign those contracts. I do it myself I have to admit that.
I'm going to skip to the last one. The last one is really kind of the big one.Enterprises need assurances. I always say that this is kind of like dating. I can tell a girl that I'm a great guy. I am awesome, go read my Match profile, my match.com profile. I am awesome, you'll love me, I travel, I'm well educated, I'm articulate most days, maybe not today. I can tell them all I want, but until I prove itand they see it, they don't care. Security is much like that. That's the big reason why you do this.
Other than just doing the whole right thing, we're going to leave that kind of off to the side real quick, our enterprise morals. But from a business standpoint, you do it because you need to show that you're legit. That you're a real company. That you take these things seriously. Now, to what degree you do it, that's a different story. And it's not always created equal when you're getting audited, but you have to something and you have to show that assurance.
I spend a lot of time on this topic, because I struggled with this early in my career. I was very egotistical about: I am the expert in this, why should I have to prove this, I know what I'm doing, why would you ever question me? Granted I started my career when I was like 16, and I was a dickhead, but it's the fact that I see myself now and I turn around and tell my staff, and I go well show me. How did you arrive at this conclusion? It's that whole assurance thing. So again, it's much like dating. I use that analogy quite a bit these days.
The other stuff is loss of market leadership, and all this kind of stuff that comes with losing your IP and those kind of things. The very last bullet point is an interesting one. Somebody's ass is on the line. If you're doing business with an enterprise, there's some security guy somewhere in a cube farm in whatever city. He's got to make a decision of whether he's going to let a certain type of data go into your product or use you for a certain kind of service. And he takes that very, very seriously. Because at the end of the day if your solution gets compromised, it's him that they look atand him whom might get fired.
Security people are the notorious scapegoats. Everybody who has ever been in my role has always been scared of being the scapegoat in two years because a breach is going to happen and they turn around and go, "Well you're the security expert. We got compromised. You're fired."They put out a press release about that:"Hey we replaced our old security team, stock is back up." I've seen that many, many times.
Take in the personal side of this and that also kind of plays to when you go through reassessments and talk to their customers. How many of you have talked to enterprises already that start to bring up security or want you to talk to security staff? Okay, a couple. Have you found that relationship to be kind of like they're your adversary? Kind of battling, or has it been a good relationship? Some, yeah.So most security people are dickheads. Just know this. I am. They're just assholes, to be completely honest. It's their job to find a problem in your product, so they're going to sit there all day.
Get over that part and remember that they're human, and help them with their job, and it goes much, much easier.
Into the last slide. These are the things that I used to tell my bosses that I worked for that didn't want to fund my security teams. I had to figure out models for ROI for security. My cofounder, he loves to just randomly tell me security has no ROI. He knows how it pisses me off so much. I've spent just like a decade in it, and having a whole company around it. But he also likes to just come over to me with random things.
He goes, "If we put in this control and it costs $200,000, what's the ROI? How do you justify it?"And I'll build him a whole deck for it. I'll be like, "Here you go. This is what you would do."He loves to try to stump me on this. This is a random thing we do, especially when I'm drunk. That's his new thing, is he waits until I get drunk and then tries it and I'm still destroying him. So I'm better than him. Caleb, if you ever watch this video, I'm better than you. Okay, just a little shout-out.
Market leadership because you're going to gain your customers. If you're a small company, and you can gain one or two notable enterprises, big-name enterprises, you can take your market. You can take a lead against everybody else that's your same size, and then if you have other companies that are already established or more big enterprise that you're competing with, you're the breakout, you're trying to disrupt the market, whatever it might be. Whatever the new terminology used on TechCrunch this week for changing the market is. You will be able to actually prove that you are a player, and then other companies will look at you.
When we started our company, first thing I did was, I went and got two companies that I knew that would resonate with the other customers I wanted to target. AndI haven't had to look back. It's been really great.
So now the "hows." Let me ask a little bit, other than just getting the customers, what are you guys struggling with from a security standpoint right now? Is it technical aspects of it? Or it just where to start or organizing it? Prioritizing. Yeah, that's fun. Anything else? Okay, we'll start with that.I have that right in the middle of the slide.Perfect, awesome! I thought I was going to have to change slides. I'm very happy.
Let's start with prioritizing. I'm going to jump around the slide a little bit. Prioritizing security is a pain in the ass for the reason that it feels different. We feel like security is different than when we prioritize features for our product, or we prioritize how we shop at the grocery store. The fact is, it's a process. It's the same as what we're going to do anything else.
All of you in this room, you look at your product and you say, "I have this huge list and I have like four years worth of work, where do I start?" You guys know that pain of figuring that out. Security is the same process, though. You look at it and you say there's something on this list that's more important. And how do you define importance? Normally with security and risk people, it's defined on risk is probability and impact. It's what impact would this have if somebody compromised my Rails app?What's the probability that it's actually going to happen? Is there a worm for this vulnerability in the Rails framework?And that's how security people look at it.
I'm guessing that most of you are going to have to uplevel it a little bit and also weigh in the business side of it, which is unfortunate because it's much easier just to look at the technical side of it. And I'd love to do that all day long because business just complicates things, customers and stuff. Why deal with that?
What you have to look at though is: What's going to give us the biggest traction forward?It might not be solving the biggest security hurdle, or vulnerability, but it might be the thing that gives you the biggest traction with the customers that you are talking to. Your customers may be coming to you and saying, what I really care about is application security. Web app security, SQL injection, cross-site scripting, all of these things. They may not be asking about your background check process. They may not ask about your infrastructure patching process.
They may say, what we really care is about this abstract stuff. If you hear that 3 out of 4 phone calls,and that's what they focus 90 percent of the time on,then from a business priority that's probably going to be the highest priority. Just like if you get on the calls with your customers and your customers say I need this feature, and that's the one you hear the most, then that's probably where you're going to focus some of your time.
What I always say is find the stuff that's the big wins, that will move you forward as a business, and that you can also tackle to show that momentum and start to build that culture of security.
But to back up a little bit, I have one principle. I don't know if James still in here, I think he ducked out. I'm going to tell a story about James here in a second. Oh no, there he is, he's behind the pillar. I believe in making security frictionless. The problem with security and the reason we all hate security, the reason my company even existsis because people go around it because it's a pain in the ass. They don't want to do it because it messes up their workflow, it's extra work, it's this other project, it doesn't make sense. You have to make it frictionless. So you have to find ways to build it into your culture, especially from an early stage if you can, and find ways to make it easy so people don't have to think about it and you have less processes.
For instance, when I started at Heroku. Heroku was a little scared of me, to be completely honest. I was this big enterprise hire that came into Heroku. I'm in a room with a bunch of developers. They didn't know much about me other than what they saw on LinkedIn, which is a completely pitched position for big enterprise, Fortune stuff. They were like, oh, crap, this guy's going to be an asshole. Literally, one of the guys told me that. He thought I was going to be an asshole. Luckily he told me this after he didn't think I was an asshole anymore, otherwise it probably would have set us on a bad track early on.
I hada meeting with James one day, maybe the first, second day, something like that. We were talking about random security controls, things that people had brought up and what we should do.I was like yeah that's a legitimate control and he had concerns, rightfully so. His job was to push me. His job was to make sure I didn't screw up the culture at Heroku. His job was to make sure I didn't screw up the lives and the productivity of everybody around me, just in the name of doing my job.
There was a question about endpoint security, laptop security, and he was like,"Well what about this, what about that?"
I was like, "Well, you have SSH keys on there, you have this..."
He goes,"So how do other companies do it?"
I go, "Well, they would put all this tons of endpoint security software on there and encrypt it, and put your AV on there and decrease the performance by 25 percent. It's a great pain in the ass."
He goes, "So how can we do it different?"
And one of the things I was very scared when I went into Heroku was that everybody told me they don't accept the status quo. It was always about innovate. And that's also why I liked it and went there, because they built that culture.
I said, "You know, there's this thing. I have an idea. You can do a key management serverjust like you do a crypto keys. It's checked out, temporarily used, destroyed after use.It reduces your risk window to a really minimal timeframe. This will be great and it will alleviate the need for these other four controls."
I found a way to do something that was frictionless. In my company now, we have a command-line tool that we use for various things, automation and whatnot. In that command-line tool, I built in auditing. When you run that, it will actually audit the system it runs and says, okay does it meet all these standards and these configurations that we have to have in place?
I didn't want to build an audit team. I didn't want to have to walk around all my guys and say hey, how's your laptop configured, is it configured properly? So I built it into the tool they already usedwhich auto-generates a report every time they run it. It just goes and logs into the database and I can go look at it if I need it. Or better yet, I can show it to my customers.
And now my customers say, "Wow! You're this 23-person startup and you have continuing auditing of your controls, which Fortune 100s still can't do."
They loved that. That gave them an assurance that I was actually thinking about security. I wasn't doing everything, I'm still not. I have a company of some of the best security people on the planet.Who's familiar with SQL Injection? My CTO, you can blame for that. He's the guy who discovered the entire concept of SQL injection. So you can write him an email email@example.com and blame him for having to deal with that because he's a dick for finding that. He's messed up all of our lives. But those are the kind of guys I have, and even we're not perfect. So trust me nobody's ever going to expect anybody else to be perfect.
The next thing I always say is after you build that culture of frictionless, is to understand the customer's wants and needs. Again, I'm going to go back to my dating scenario that I use a lot. My board loves that I do this. Actually, they're quite embarrassed by that fact, but that's another story.
When I go out on a date sometimes, or I have a girlfriend, which is rare these days, girls will tell me, they'll tell me stuff and I'm not really understanding it. They're telling me what they want, but I'm not really understanding what they need from me. They need me to call them more. They need me to not be an asshole. They need me to not be in my office 19 hours a day. This is stuff they need. They're saying, hey, I want to do dinner, I want to do this. And I say the same thing back to them for the things that I need and want. So customers are very much the same.
It's just like from a product standpoint, so I'm going to try to put this in terms that are relevant here. You guys hear from your customers, they say they want certain things, but you have to distill that down to what they really need, and what they're really trying to communicate. Because they're not always good at that. They don't think like product people. Enterprise security is the same way. They're going to come in, they're going to give you this huge list, and they're going to sa this is what we need."Nah!That's what you want. What do you really need?"
You take that list and you talk to them and you find their concerns, and then you go back to the prioritization, and you prioritize the stuff that they tell you they really need. And you say, if I get these three things in place, can we do a deal? And most of the time they're going to go, "yeah,"as long as you have a roadmap for the rest of the stuff.
Once you get that frictionless and think about how you're going to build out your security and get that into your culture, then there's understanding those needs and wants, then there's prioritizing. Then you can just kind of go from there to build out your ownership, and learn from people in the market that have already done this before.
Ownership is one that's really, really important.
How many of you have someone in your company right now that "owns" or "champions" security? Okay, a couple. That's actually more hands than I expectedto be completely honest. Security is one of these things that, it's like anything else, like product management or sales or marketing that there's probably going to be a lot of people involved in it. But you have to have an owner, somebody who is just kind of herding the cats in the right directionand saying we have a strategy, and we're going to execute on the strategy and this is the direction we're going to go. And making sure that you're meeting the needs of those customers, and that everything is going well.
I also believe that you should mix security in and it should be everybody's responsibility which comes back to that frictionless state. If you have a team of engineers and you have an architect, maybe that architect is also thinking about security. Are we doing things secure, or are we doing things the way we should, or the way we'd want our data handled? You have that executive owner, that technical owner or whoever it is, that is that kind of champion and that's able to communicate security strategy inside the company and transparently outside the company. That way you know that it's moving forward, and where it's moving forward.
I'm going to go through a couple of these, they're going todive into some of the points that we have. But, like I said, if you guys have any questions or if you guys want to go down a different direction, holler out. We can totally go down different directions. I am well prepared for you guys. They scared me. They have a very professional setup here and everything, so I was like I have to be on point tonight I guess.
We talked about this a bit, just make things frictionless and build things into what you already do, so you don't have to choose a bad option. The good option is there, it works and you can already take it.One of the things I always talk about here is using vetted libraries. There's tons of libraries out there that have invented from a security standpoint, or have been custom built for security for sanitizing inputs. By the way that's the $300,000 consulting secret right there.
If you sanitize your inputs and outputs of your product, you will stop 90, I'm going to go 95+ on thispercent of attacks.YourSQL injection attacks, your cross-site scripting, all that. You're going to make your app security side of the world much, much easier. Spend time on that if you spend time on anything.
You use those vetted libraries. You use the tools that are built into what you're already doing. You're going to save yourself time, you're going to save yourself headache, and the right option is just going to be there. Nobody's going to have to make a tradeoff in a pinch of do I have to ship product, or ship secure product? It's just there. And that's what you really, really want to strive for from an early stage.
We talked about this already, boiling down what the customers need. This is my favorite example, PCI. Have any of your customers asked you about PCI compliance? Okay, out of the ones that raised your hand, are you in scope for PCI compliance? These are the answers that are interesting, the not sure and probably nots.
Enterprises will ask you if you're PCI compliant, or what you do for PCI to meet PCI compliance even if you're not required to be in scope because it's a measuring stick. They don't know what other questions to ask. They don't know how else to gauge you and measure you, so it's a common criteria. They'll come to you and they'll say,"Well you have to be PCI compliant. And you go, "What's your need?That's what you want me to be, what's your need?"You boil that down to the exact needs and a lot of times this question will just go away and disappear. It's an awesome one. So that's why I called that one out.
The next thing I'll say is understand your risk and the concerns you have in your business. Each of you has a set of concerns that are in your head all day long as you're running your companies. As you're building code, or shipping product, you have some concern whether it's running out of funding, hiring new staff. Which, I hate recruiting, I hope everybody else hates it as much as I do. Otherwise you guys have better recruiters and that pisses me off. You have concerns. You should be thinking about your security concerns as well.
You can look at your product and you can say, how would I break into this? What aspect of my product would I be scared to use my own personal data in? If you put your Social Security number, you put your bank account information in there, would you feel comfortable end-to-end through the product?Vendors interacting with it, your staff interacting with it, all of this.
Put yourself in the seat of your customers, and all of a sudden you'll figure out where your biggest concerns are in your product. Then you'll be able to look at that, prioritize that, and then internally use that as a motivator to drive that security culture.
Security culture internally is a big thing that you have to really own and champion to push forward before you can ever really address it with your customers. Because if you get too much pushback inside or people just aren't adopting it and doing it, it's almost for naught. Once you know all that, then you can define those risks, you can prioritize them, and figure out how to tackle those.
Again, we talked about this, but it's the biggest wins. You want to focus on the biggest wins. So your biggest win may be technical, or it may be just documenting what you do. I had a very specialized security career before I came to the evil vendor side.I specialized in building and rebuilding security teams. That's what I did. I came in, you either had nothing or something went upside down, and I came in and I either built teams, I gutted teams, but that's what I did. I was restructuring for security.
The first thing that I've always done, I write down all the concerns that I have and then I start to prioritize that. Then I figure outwhat are my biggest wins? What are the things that customers are asking for? Nine out of ten times, it's simply documenting what I already do and documenting what I'm going to do.
That simple documentation not only gives me a roadmap internally just like it would for a product, but it also gives me something to hand to my customers, to talk to them and start the conversation. I find that you have to have that to start the conversation to understand what their true needs are, otherwise they write you off.
There's a large company, I won't name them, but there's a large company that had a breach a few years back when I was at TiVo. Their product came in and somebody in our legal team said we would really like to use this product. It was going to have very, very sensitive data in it. Stuff shared with our board, very, very sensitiveproduct stuff, litigation stuff. If you know anything about TiVo, their whole model is basically being an IP troll these days.We couldn't allow this to get compromised.I was a little concerned about it, so I had somebody from my team contact their security team, no answer. I called somebody over there, no answer.
Eventually, the CEO of this Fortune50 company called the head of security and said, "Why have you not called TiVo back? We need to close this deal." Turns out, that he just didn't want to show me anything. Turns out he didn't have anything to show me, so he didn't want to have the conversation. Deal stopped right there. I didn't care after that, the deal stopped.If you can't be transparent with me, you can't show me, and we can't have a a conversation, deal stops. Had he just shown me something and said, "Hey, here's what we have going on, here's my roadmap,"I would have probably accepted it and said,"Oh this is good, okay, let's work towards that."
This is where the prioritization of just writing it all down, working with the customers, figuring out what you can tackle, and then going from there.
If you get to a point where you hire a CISO or a head of security, please think of them as kind of a product manager over your security. Don't think of them as the security wonk in the corner that wants to say no all the time. Think of them as somebody who actually will champion your security, and use them both on the internal side and the external side.
This is one of the things I'll give James tons of credit for when they hired me. They let me have reign inside and go talk to the customers, and I was able to connect the two and find the right strategies for the very short period of time that I was there before I became a defector and started my own company. So anyway, that's prioritization.
The next thing, and this is an engineering trap. Not to offend any engineers in here, but I yell at my engineers all day every day about how much I hate them and the way engineers think becauseI think more from the business side. I see a lot of very, very smart technical people try to reinvent security. They try to find some new process, some new thing, some new way to do it. This shit ain't new. That tip that I gave you about sanitizing your inputs and your outputs of your product, that was in a book written in 1979; 1979 and we're still screwing this up. So this shit ain't new.
Learn from the people that have been out there. Go check out OWASP. Go talk to the experts. Hire consultants. Consult me.Call me, I'll help you out.
Go talk to people and understand strategies and how you can move forward and where to start, and how to tackle things. Don't go out and try to find a new thing. It's like doing crypto.
Anybodyâ€”not anybody, but 99 percent of peoplethat try to invent their own crypto, they fail. It's horrible, it's useless. They're not smart enough to do it, me included. I am not smart enough to do it. So we don't do that. We reuse it. Security strategies are the same way. Use the frameworks that are available to you. Use the processes that are available to you.
There are maturity models, if you're one of the people that subscribes to that kind of thought. There are just simple processes that you can say, "Here's a checklist that's a security baseline that all my customers are asking for. I'm going to prioritize what I can do on this and what is asked for the most. And I'm going to start building that roadmap and build my documentation and be transparent and go down that route."
I see too many companies fail because they just they try to reinvent the wheel, and it makes no sense to me. It's a fun challenge I guess, but one I wouldn't take on personally.
The ownership one is an interesting one to me. I'm going to talk a little about org structure here as well. This is a little controversial inside some of the big companies, but it's going to help you guys out a lot. You need to have somebody in your org that really champions security and drives security forward. Somebody who, like I said, kind of herds the cats in the right direction and says, "This is our strategy, this is where we need to go,how are we getting there?"
Just like you have a product manager, or Google has like 300 of them, think of security the same way. Somebody needs to champion and push it and own it and say this is what's best for the company, for our customers, for the product, whatever it is. But the tactical level, this is what's going to be a little more interesting I think. The tactical level is where people tend to have a hard time. How do you execute on it? Do you hire somebody and say, "You're the security guy, go work with all the teams and go do the work" or "You're the security guy, go project manage basically all the security."
I believe in a model, and this is a model that's caught on the last few years. Actually probably less, five to ten. The Fortune 100s are still a little slow.I put this in at Disney, I put this in at TiVo, Citibank actually does this now in certain divisions, just to show you even staunchy East coast companies will do it as well.
It's to basically say, "I have an owner and I have somebody who is keeping track of security, but we're going to spread it out, or spread the responsibility out."We're going to say, "You know what, in this team over here of rails developers, you guys are experts. You guys know the product. You guys know the code. Somebody over there needs to be the liaison or the owner in thinking about security for that component."And over here maybe there's a java team, orover here there's an infrastructure team.
You basically have people at the tactical level who are keeping track of it. Who are, I don't want to say gatekeepers because that sounds too process oriented, but are kind of the guardians or kind of the product managers, or the junior product managers for security at that tactical level. You have the champion, the executive owner or whoever, who's making sure it's all going the same direction and everything is getting done that needs to get done and things are getting prioritized.
Inside the individual teams now, everybody's involved in security. This builds a culture of security, and this also puts the people that actually know what they're doing in the place that they can execute and do it.
I can't tell you how many times in my career I've been brought into a meeting with a bunch of engineers to say we need a security guidanceon this product or component or whatever it is. Only to spend three hours for them to explain to me how it all works, for me to give them 20 minutes of advice of what to do. Not time well spent. I mean for me, great! I was learning some stuff and got me out of some meetings. For them, I'm sure they could have been doing much more interesting things than babysitting me all day.
By distributing it out, what's going to happen is you're not going to have to staff up and say,"I'm going to build this big security team that's over here that doesn't really understand product and doesn't really understand what's going on,that's going to fight for prioritiesand try to get their projects in over somebody else's project."
It's with inside the teams. All of the teams now have ownership for it. All the teams know what they should be doing. And it's going to work and it's going to help you grow.
Now eventually, your companies will get to a certain size where you need security operations peopleand testers and all this stuff. That's different. But at the early stage and at the product stage really think about that tactical ownership. Because this is one of the biggest stumbling blocks most companies run into, not the technical aspects of it, not even figuring out what to do. Just the how to do it and who owns it. This is one of the biggest areas I see companies run into problems.
Q: How do you get people to take on that additional responsibility?
A: I generally find that one, if you have that champion that's an influencer within the organization, and they really put it out there as this is what we're about. It's not just, we're security to get enterprise business. It's, we're security to protect our customers, protect privacy, really the right reasons, people will step up and people will want to do it. It's very few cases I've ever seen where there wasn't somebody that didn't really want to step up and say yeah, I want to be involved in thisfor my team, I want to own this.
If you don't have that case, or if teams are small or it's a single team at smaller companies, really it should just be part of your general discussions. When you're looking at your product andsayinghow are we going to do something, everybody should be thinking about it. You should just make it part of, I hate to say it this way, but part of the job. Everybody should just be thinking about it and everybody should be responsible for it. You measure the security defects that come out, that are found through testing, just like you would any other product defect.
Like in my company, if somebody breaks a build that's going to go out, they are flawed and they actually have to buy the entire company milkshakes. I don't know how we started milkshakes, but we have random things where the punishment is chocolate milkshakes. I'm going to be a fatty one day, I'm sure. We do the same thing with security defects, andI have in most companies. I treat them as any other product defect, like a P0, P1 or whatever system you guys use and it's a bad thing to get those. If you build in that culture, it will work even if you don't find somebody who will step up. But most of the time I find somebody who steps up.
Communication and transparency, how many of you are scared to tell your customers what you're doing about security right now? I see some head nods, I see some hands. I know you don't want to ever admit that in front of other people, especially if there's a camera. Don't worry they didn't turn it on you guys. It's still on me. Most of my career I was always scared of this. I was scared to tell the companies what we were doing well, what we weren't doing very well. What I found was, it was like any other product discussion or sales discussion.
I just open-kimonoed it and said, look this is what we're doing. If we're not meeting your needs, we're not whatever government certified, then we're probably not the right business for you. You need HIPPA? I don't want that liability. Here's another company you should go talk to. They're going to meet your needs.
I found that it was a much easier conversation to be open and transparent, than try to hide it.
I had a boss one time at a company early on, he literally tried to hide stuff from auditors, and they tried to fake configurations and all this stuff. We're talking like board-level fraud. This actually got him fired as well. At the end of the day, he spent more time trying to lie about the security of the company than actually trying to fix the security of the company. It was ridiculous.I would say be open, don't be scared. Obviously, keep what you need to keep secret. It will ease the customers minds, you'll build that communication path and you can show your customers that you're thinking about security.
Literally, I can't overstate this. Creating a simple document that says this is what we do about security, even if it's just a couple of paragraphs:We have passwords. We use SSH keys. We use access controlled volumes. We encrypt this kind of data. Anything, even if it's just simple. They will appreciate it.You're not going to nail every customer with this, but they're going to look at it and go, okay now let's have that dialog. And you're going to get much further than you would have if you had nothing or if you tried to hide it. I can never overstate that.
You can go to policy.heroku.com. It's still up. I found a typo in it the other day. I had to send it to Oren. I wrote that. I wrote that probably my first two weeks at Heroku. I didn't know very much about the internal security. But what I did was I collected all of the documentation that I could get from AWS and from the product team at Heroku, and the stuff that I already knew that we were doing, and I just put it together because I needed a starting document. I needed something to start with so that I could understand what we were doing and I could start to have conversations with people about where we needed to actually be. So back to the customer needs.
You can go look at that, policy.heroku.com it's the security overview document. If there's any typos, sorry. I don't have access anymore. It's very, very simple. You'll see what I'm saying when you look at that.
The final thing on this one is really find the verticals that you're trying to target. My company, right now we have an element of our product that's in the cloud, and we have both the control channel and a data channel. Enterprise data may come through us in certain cases. There's some verticals I just don't go after yet because my processes aren't mature enough, my product, my security (and I employ a company of almost all security people) is not where it needs to be to tackle those verticals.
I'm very self-aware of what are good targetcustomers, and what are going to be customers that I can't break into that market yet, but in six months I'll get some of them. I'll get the early adopters. In 12 months, I'll get the mid ranges. In hopefully less than 18 months, I'll have the biggest names in that market that are the most conservative. Once I have them, I can get everybody else.
Be very self-aware of that and know that it's okay to say I need to step away from some business because of security. Sometimes that's the right decision. I've had to do that myself andI don't like it.
So to the meat of it. Where to actually start? This is just a quick list, high-level, of some of the top concerns and questions you're going to hear from enterprise customers. This should look familiar to you guys that have been meeting with enterprises.
First thing is, if you have their data or their customers' data, they always start talking about that. PII and privacy and breaches, and whatnot. We're in the age right now of every week I get an email going, "Hey, we've had a compromise. Please reset your password." This is becoming the norm these days. This is where all the enterprises start. It's all about that customer data. It's because that's the most valuable asset generally they're giving you, and it's also the highest risk. They have the biggest liability if they lose that.
I talked to a guy at a big bank I used to do business with at one time. I said, We just have this little flaw in our product, everything's good and nobody exploited it. We found it, but it was a little close."I said, "What happens if I lose some credit card numbers?" This is the bank that underwrites the card. I said, "What happens if some of these card numbers get compromised?"
He goes, "Eh, we'll reissue the cards. We'll come down, we'll do an audit, and whatever."
He goes, "Yeah, but you lose a Social Security number, we're going to sue you out of business." A
I go, "Okay, that's about right." But I asked him, "Why?"I'm a little naive at the time asking why.
He goes, "Well we're the bank. We already have all the money. We can just rewrite the credit card. Like whatever, it doesn't matter. It's our liability anyway and we can take care of it. Social Security number, I can't reissue."That's why they were so worried about thatbecause that was the highest liability data.
Understanding where the customers are coming from helps you start to prioritize and where to actually start.
Then as you get through all that, app security is what comes in. Generally app security will either be the lead or right behind customer data because most likelyyour company will be compromised. Go ahead and realize that. Most companies on the planet get compromised at some point. Most likely if it's an external attacker, it's going to be through a web application vulnerability.
As mature as this market should be, we are still not there because it's humans writing code. It might be in your code, it might be a code that you use, whatever it might be. That's where it's the easiest path. You're going to find a defect that somebody created in the product and your web application is what's exposed. It's the easiest target.It's usually pretty vast, complex web applications these days, so that means lots of lines of code, lots of opportunity for defect, and this is where you're going to be attacked most of the time.
Almost all of these password compromises and things that you see come out, "I got breached" and credit card numbers got stolen. Almost all come through this. You'll read the news and they'll talk about malware and APT and all this. Don't get distracted. That's us security guys trying to sell more product. We have to scare you guys so that we can get bigger dollars. My entire market is built on FUD. It's great. I love it.
Your application security, once you understand your customer data handling â€”who has access, how do you store it, how long do you store it, all that kind of stuff,your app security is generally where you want to look next. And very quickly. Followed by your infrastructure security because that's also forward-facing. Then you get more into your internal stuff. Your internal access controls, your policies, getting third parties to come in and audit you, all that kind of stuff.
A secret in the security world â€” most companies: hardened shell, gushy gooey inside. Security at most big companies is really soft on the inside because the risk is really the external-facing stuff.
There's all these studies that come out and sayyour biggest threat is your insider threat. I've been hearing that for like 15 years. There is not a single study to ever back that up. Your insider threat can do the most damage, but it's usually the less probable attacker. It's usually your external that's always going to be the one that screws you at the end of the day. Work on that stuff that's going to be customer-facing, that's going to be really around customer data. Start on customer data and work outward, the applications, the infrastructure, etc.
Then you're going to be able to go back to that whole assurance and showing your customers and communicating. You're going to say, "Look, I take your data and the applications and systems around that really seriously.Yeah, I may not have these other processes in place, I may not have AV on every laptop. I may not have encrypted drives on these laptops. But, my security around your customer data is so good that it mitigates for these other things."
When it goes back to prioritization, this is how you really slingshot yourself ahead in this conversationby really addressing their core need. This goes back to their need, not their want â€” their core need â€” by doing the things that give you the biggest win and are actually addressing the largest liabilities for enterprises. Because enterprises care about two things, cash and liabilities. That's more or less it, actually.
Third-party audits, any of you going through any third-party security audits right now? Okay. Eventually you guys will be asked to do this. Customers will come in, especially if you're dealing with any sensitive data. They'll say, well okay that's great that you've told me that you do all this and you can show me some documents, but has anybody else audited you? Be open to those companies auditing you. Be open to those companies sending in their third-party auditors.
One of the banks I used to work with they would send in their third-party auditors to do source code reviews. These were like $200,000 engagements that I didn't have to pay for simply because they wanted assurance. I was like, awesome, free security review. I mean this is $200,000 not out of my budget. This was great. My boss at the time was freaking out.He's like no, no they're going to know what all our problems are. Either they're going to know whatour problems are or they're going to cancel the contract. Whatever, I really get something out of this if it goes upside down.So, eventually you're going to be asked for that. Welcome that and everything.
And we get to the "when." I purposely put this in reverse order instead of putting when at the beginning. Normally, when I have this discussion I talk about the when, but I wanted to drive home the points of transparency, prioritization, and really customer need before I talked about the when. Because the when you start security is kind of a no-brainer actually to me.
You start as soon as possible. You start today. You start thinking about right now what your risks are and what you need to do.
And you go back and whoever your council is in your company, whoever it is that are the thought leaders, the influencers.You start talking to them and saying, "Hey, how many security questions do we get on a weekly, monthly basis. Hey, are we losing deals because of security? Hey, what are we doing about security? Can I put my personal data in this? Would I trust it?
These are the conversations you should go ahead and start having. Even if you're not in a place to execute, go ahead and ask the questions. Go ahead and learn, and go ahead and get that conversation started inside your company. Because it's going to take time to get that ball rolling and get that culture set in your company.
From a true business standpoint, you do these things when you have to. And when you have to is normally either, somebody has told you you have to, an existing customer, you're losing business because of it, you've been compromised, or you're just being attacked a lot because you're some really high-value target.
Let's go back to my Facebook example for a minute. Facebook, amazing security team. One of the best incident-response teams I've ever seen inside a company. Like, non-IR consultants. They were getting attacked so much that they just had to go staff this security team to go deal with spammers and go deal with compromisesand attackers and patching of applications and testing.Because they realized to be this massive brandand be this billion dollar whatever company that they wanted to be, that they could not lose the private messages of their users. That's about the most sensitive thing they have.
They got the private message that I sent to my girlfriendlike, "Oh my god I love you so much. Yes, I will totally take you on that very you-know-date that I would never admit to my friends that I'll take you on." I don't want that public.But, it's not a big deal if that went public? It's not my credit, it's not my identity. Yet they realized that they had to protect their brand if they want to be this massive company because they had so many users.
They're an interesting case that I was reference back from because they didn't have the monetary revenue. They didn't have like,"Oh my God, there's been a big compromise, now we have to show our shareholders that we're responding" kind of thing like Heartland Payment Systems did. They just simply said this is the right thing. I really like that model. And this is about the only time I'll ever reference Facebook as a business. I still consider it a toy where I post photosandmy friends check me in drunk.
The biggest thing is really just time security to when you need it just like you would for a product roadmap.
You build a product roadmap for when you need to ship features. Security, you should be looking forward to that. So that's why you start now to understand your culture. Understand the drivers. Understand the questions that are coming in. Then you can say how long is it going to take me to get there? How long to do the things I need to do, or to have those conversations, or until I'm comfortable having those conversations with my customers or potential customers?
You start early and then you really just target to when you need it. Now, most security people and hopefully none of them ever see this talk, but most security people say,"You have to do it now, the sky's falling, all this."You'll find that I'm very balanced, because I've been through it. I've been through compromises, I've been through big companies, small companies.
Realistically it's security has a great ROI, especially for small companies trying to disrupt a market and get big enterprise customers. But it's all about timing and when you do it. Don't spend your resources and spin your wheels too early because you probably have more valuable things to do.
Even me as a security company, that's our strategy to be completely honest.
Once you figure all that out then we talked a little about the hiring, eventually you'll have to hire dedicated people because you'll be big enough. But part of that, involve the people that want to be involved. Find the people who will champion it from inside and will build it, bubble it up from the bottom while you champion it from the top down or whoever it might be.
That's the meat of the how, when and why.Now I want to turn it over to more questions so we can dive into whatever might be specific to your needs, where you guys might be struggling or questions you guys have.
Q: When meeting an enterprise customer, what should you be transparent about?
A: Sure, that's a great question. I say be as transparent as you possibly can. Anything and everything that you can show. But to dial that in a little bit more, it kind of goes back to what your business is and what the needs are of your customers.So if you're handling customer data, then you want to show how you handle that data in a secure manner.
Anytime you have customers in the system you want to show how you're handling their data or how you're providing your service in a secure manner to them.
You want to go down as granular as you can to say, "We control who has access to this data. This is how long we keep his data. This is where and how we store it. We have it on servers and segmented networks. We have it encrypted. Here's the key management." You actually want to put a high-level narrative around those things to really make that transparent, let them them be comfortable and have an ease of mind. Then you want to step out and say, "Okay what's all around that?"It's just expanding out. I believe in a model of you apply security to the now.
My brother, the cocky bastard that he is, he's a Navy Seal. And he will tell you he's a Navy Seal all day long. He's very cocky about this. But there's one thing that I learned from him that I loved. I said, "So what's your mission?" He goes, "Protect the now." I said what's the now?" He goes, "Whatever's valuable.I don't know until I get there, but I'm going to protect it whenever I get there."
I say the same thing to security all the time:Apply your security to the now and work out from there.
When you're communicating to customers,what they are concerned about is their customer data or this service that I'm providing to them, hosting or whatever it might be. I'm going to show them everything that I do to protect that and then work my way out.
The high-level low that you always want to show is your customer data security, your encryption, access controls, your application security, your infrastructure security, your logging, and your policies. Those roughly seven things, those are the core to all the 400 questions that you might get from enterprise security teams. Those are going to cover all the biggest threats and biggest areas.
If you've run code analysis tools, if you've run white box or black box auditing tools, share the summary of those reports. You don't have to give all the details. You don't have to give your code or anything like that. Share those. Say, we ran this vulnerability assessment. We actually came up with four high findings, and high is not always created equal, but we found four high findings. This is our plan to fix them, or we've already fixed them and we did it in 30 days or 60 days or whatever it is. Show them that stuff.
If you can show them around vulnerability, if you have it if you get to that point, customer data handling, storage encryption, access control, logging, app security, infrastructure security, and then policies and if you have any yet, those are the core things to start off with and to try to provide.
Q: What are some things you should or shouldn't sign in a security contract?
A: Never sign any contract you don't have to. That's my general legal advice. What's going to happen, this is always interesting because I've given people advice. I think it was three months ago I spoke at a conference and I was giving advice on how to write contracts, how enterprises should write contracts when doing business with SAS services or cloud vendors and everything they need to shove into that contract to make sure they're protected. So now I'm going to give you that advice. That's interesting.
The things that you have to look for are the unlimited liability, what constitutes a breach, or what can cause you to have to do a security disclosure, an incident disclosure to them.
What'll happen is many of these customers they think they want to know all this stuff, but really they can't handle it when you send it to them because they freak out.You finding a vulnerability, you perform your own scan of your own application, you find a vulnerabilityâ€”I've seen contracts where that constitutes having to tell the customers about that vulnerability.
Well, in any reasonable enterprise, you're going to find thousands if not tens of thousands of vulnerabilities in a few months' span across all of the infrastructure. Enterprises, customers don't really want to know all that, but what they want to know is you had a breach, or you had a third-party notify you about a vulnerability, or you found a vulnerability that maybe you think somebody exploited. That's what they want to know about.
They want to know about the stuff that actually might have affected them. So be very careful around that liability and around that disclosure terminology.
Also, be careful of where you're at company size-wise around the audit rights. Most enterprises will try to put something in to say we have the right to come audit you. Usually there's some kind of trigger on that. Itsays, if you've had a security breach, or if these kind of events have happened, but some will put a very open-ended one in, we have the right to audit you and audit your security any time. Problem is there's no scope there. If you read up in the contract and you read about any other section of the contract, there's some kind of scope. It's limited to the business, it's limited to the revenues, or the cost of the product, whatever.
The security guys are really good about leaving this wide open. Be careful about that and say we encourage you to come audit us because we have nothing to hide. But let's talk about this. It's once a year at your cost, or whatever. Don't necessarily take the burden of that. It's not every week, it's not on a whim, and it has to be either just an annual thing or a six-month thing, or based on a breach or a compromise. Those are the biggest ones that I would watch for because those are the ones where I screwedcompanies quite often in my contracts to be completely honest.
Q: What is too much transparency? Should I disclose on my website if I've discovered a vulnerability?
A: I would say that's too far.Companies want transparency, but if the enterprises are using your service, your platform, or their data is in it, they don't want anybody else to know what problems exist. I know a cloud platform right now that they want to have a bug bounty program. They want to allow hackers to come play and test and try to find vulnerabilities, and they'll pay them for it. But the problem is, they're large enterprise customers freaked out when they ran this idea past a couple of them. They were like, no, what if they use it against us? So the same kind of thing.
Even if in a vulnerability report all the vulnerabilities have been fixed, the problem is it will show a pattern. If I read your vulnerability reports, and I read two or three of them, I will see a pattern. I will see where you're weak in your security processes and where your STLC is just falling down, and I'll know exactly what to attack. This is a little too much information.
What I would do is, put out there these are our guiding principles of security. Here's some of the controls that we have in place and things we do. We do application and security vulnerability assessments. We do secure coding, however you want to phrase this. Have those reports and send those to your customers, but not publicly.
One of the things I always do in every company is after I get my documentation and saythis is what we do,I package everything that I can and I create a security package. I have it and I give it to my sales team, and I say here is our security package. So as soon as the security guy, or somebody at this other company says what about your security, they send them over the zip file â€” the this is what we do, here's our most recent vulnerability report, here's our high-level roadmap or goals or that update maybe quarterly or whatever.
This thins off about 20 percent of the companies that are just looking at if we did something.Then it opens the door to the next about 70 percent, where I can actually get through the audits with those guys.The remainder companies are the ones that I'm just not going to close because my security is not mature enough or the deal blew up.
Have all that prepared and be able to give it to them fast, but not too public. Definitely put stuff out there that's public.Market to that.
Especially with this hot trend right now of people talking about privacy and their passwords always being compromised. Market to that. Take that FUD, turn it around and use it for your own benefit.
Q: How can I test if my app is vulnerable without asking a third party to audit me?
A: There's a number of tools that are very similar to how you would do the same thing, product testing,as well as services that are out there that will just run. They'll run web application scans, or they'll run code, static code analysis, generate reports, feed that into JIRA or whatever system you use.There's the equivalent tools on the security side.
Most of these are tailored to the enterprise, so most of them are very expensive. I think WebInspect, which was the top of the premiere web app security scanning product that had a scheduled engine, you could just tell it to run all day long. A base license was 25,000. Fortify, which was the premiere static code analyzer, base seat license of that was probably 35-40. Prices have changed a little bit since those companies have been acquired. But that kind of gives you an idea of the market on that.
There are some tools that are out there that are open source and that are great. You can look at like Nikto, Whisker, you can look at the Google guys have one for web app scanning. You're going to get some benefit out of these.
But without somebody to really review the report that knows what they're looking at, you get less benefit.
I have a lot of people who run them and go, "I got this report. What do I do?" So make sure you have somebody who can look at that.
The other thing that you can do you can look at some of these services that are out there that'll scan your web applications, if you're ready for a kind of service like WhiteHat Securityand some of these guys that have SaaS offerings specifically for code analysis and app scanning. There's plenty of these tools out there and they'll plug in to whatever continuous integration suite you're using, and generally your ticketing suites as well.
I like it. That question is actually further along the maturity model than I actually get from most security people. So that's good.
Q: What are the best practices for securing customer data?
A: Absolutely. If you have customer data, or personal data, some of the best practices, the first thing is, and this is the very simple one, only collect what you absolutely have to have. Be very mindful of where you're collecting data. If you have customers and you're marketing in the EU, the data laws in the EU to the US are very, very different. Even aside the EU, Spain and Germany are more restrictive than most of the other countries in the EU.
Only collect absolutely what you have to and what actually makes sense.
The next thing is, only store it for as long as you need to. Make sure that you're purging that data out. Set up some auto routine. Account hasn't been active in five years, move it out. Maybe throw it in the marketing system. But reduce the number of places you have it and purge it out as often as possible.
The next easiest one is access control. Make sure you understand who has access to it, how they gain access to it and there's logging of that. Those basic minimums right there will help you meet things like safe harbor requirements. They'll help you meet the 37, I think it is, data security laws in the US now that have popped up in the last about 2-1/2 to 3 three years. Those basic three things will get you there.
To go beyond that, encrypting the to data is always a really good thing to do. Especially if you use third-party vendors to store stuff. Anybody who might be an EC2 or other cloud services, you don't always know where that data is going to land. You may have a residency prob and it may go to a country that it shouldn't have. Not like, North Korea or Iraq, but it may be EU data that ended up in Asia and it wasn't supposed to.
Encrypting will help you fight the liability or any problems there. Also, it'll help you secure that data both inside your own infrastructure and outside.
But if you only collect what you have to have for as long as you need to, you have access controls and you have loggings that you can say yes, this data was changed and no this data wasn't changed; orthis data was compromised or no it wasn't, you'll meet the base requirements. It's the base best practices right there. Then you go encryption above that and you're pretty much golden in most cases.
Thank you for having me. Hopefully it was helpful.