Storage Developer Conference - #16: Hackers, Attack Anatomy & Security Trends

Episode Date: August 12, 2016

Hello, everybody. Mark Carlson here, SNEA Technical Council Chair. Welcome to the SDC Podcast. Every week, the SDC Podcast presents important technical topics to the developer community. Each episode is hand-selected by the SNEA Technical Council from the presentations at our annual Storage Developer Conference. The link to the slides is available in the show notes at snea.org slash podcast. You are listening to SDC Podcast Episode 16. Today we hear from Jeff Gentry, Regional Director with an Independent Security Evaluator, as he presents hackers, attack anatomy, and security trends

from the 2015 Storage Developer Conference. So my name is Jeff Gentry. I work for Infinite Security Evaluators. Our headquarters are actually in Baltimore, Maryland, but I have the luxury of living and working remotely in Austin, Texas. So what I want to do today is kind of have a bit of an analysis on hackers and how they operate right we've all heard from headline news you know about company xyz was hacked but what does that mean you know how did they do it how did they execute that particular attack why did they go why did they go after those assets and what we'll walk away with, hopefully, is a range of lessons that we as a community of technologists can use to improve.

The goal is not to just talk about it, to actually figure out ways where we can become more resilient against modern attackers. We can better secure assets. So why is this important? I always ask this question when I'm giving a talk the attackers are becoming much more sophisticated

attack vectors are much more tall digital assets are much much much more valuable than they were and the traditional defenses are no longer the same everything that I talk about these attacks, these takeaways will support most of these points. But another question is, why are you guys here?

Some of you guys are from California, and he's from Colorado. Why do you take time out of your day to come and watch me talk? Believe it or not, I actually heard all of these excuses on the couch. Every single one. The funny one was running for the ball, got a little worn out, so we decided to go out of town

until we could get back to where we were already dealing with it. But yeah, mileage runs, expense accounts, whatever it is, hopefully you're here to learn something or meet someone. And I think there's a lot of valuable information in here. And a lot of what I'm going to talk about deals with mindset and perspective. Both the mindset of the malicious adversary, their perspective, their motives, how they attack,

but also your mindset. You as developers and engineers, how you build things, how you go about the security process of actually securing them before you deploy them. It's all about mindset and perspective. And so a lot of that will kind of be woven in throughout this talk. And so I'm going to talk about a few companies, some quicker than others.

I think the real value is in the lessons, not necessarily the attacks. The attacks are all kind of interesting. Not everyone knows how these attacks actually occur. But we'll run through Texas Instruments and Target and the iPhone.

We were the first company to break the iPhone. It's kind of our claim to fame. So we still talk about it. People still ask us about it. So as long as people still ask, we'll still talk about it. People still ask us about it. So as long as people still ask, we'll still talk about it. And that'll be the last one that I

discuss. So the first is Texas Instruments. And ISC was founded in 2005 under the Information Security Institute at Johns Hopkins University. Specifically, a lab design study.

And at the time, specifically a lab design study on the part of IBM knowledge. And at the time, Texas Instruments had this DST40 system. They touted as unbreakable. And whenever you tell a bunch of hack-a-mighty computer scientists that something is unbreakable, the response is always going to be challenge accepted. Every single time. And so what we did was we set out to design

a study to break that down. With the idea that if we're successful, there's going to be some commercial interest. And if there's some commercial interest, perhaps we should start a business. So, on paper, in a lab, by a bunch of actors, I asked this question.

And the reason we felt compelled to talk about, or to research, this particular piece of technology, the DSP-20, since we're in the communication protocol, the TI-I-I was because it was used in two very important systems at the time. The first being the Ford immobilizer key, and the second being the S-on-model speed test. Now, for the Ford immobilizer key, I mean, you guys get how keys work. You put it in the initial, physical action,

it turns into an engine. And how it was used before was there was an authentication between that key and the onboard computer of the card. Is this the right key? And with the Excel mobile speed pass, same thing. You attach your credit card to that particular token, put it on a key chain, and you have

a secure communication between that token and the gas stopper register inside. So you go inside, buy a button, get that wallet, and you can do that. So these were two very important systems at the time. And what happened was we ended up studying the technology for a few weeks, trying to figure out exactly how it was architecting. And then we spent a few weeks reverse engineering and put the back on the rest of the test. And then a couple of weeks after that, there we were, really concept.

I started to call our two-day-data letters for California. Super simple. I'm very cool. And so, after that, that's how ISC was born. There's a bunch of stuff about us that I'm not going to talk about, because you guys don't care. So the first topic I want to talk about today is Target.

And I know this happened, what, 18, 24 months ago to this point? But it's still really, really interesting because it harmonizes quite nicely with the principal message that we discuss internally. And that is all about supply chain security and finger security. And it goes to this idea of attacks, traditional attacks and traditional defensive technologies no longer being deployed. traditional attacks and traditional defensive methodologies

no longer needed to go away. So what happened with Target is one of their vendors, which in this case was an HVAC company, was the victim of a spear phishing campaign. And that spear phishing campaign granted credentials to Target's network environment

through that. And so once they got into the maintenance environment, which the reason this company had access to the maintenance environment was to perform certain operational functions, such as controlling the media and things like that. And I'm pretty sure vegetables were cruel enough to die, but we could save $17.53 per location for probably a second or three.

But the vegetables did some, certain operational functions were required. So I'm not going to go into this in a long piece. So what happened was, due to improper network segmentation, the bad guys were able to jump from the maintenance environment to the payment environment. And as I'm sure most of you guys know, this is not a good thing. And so once they were able to navigate into the payment environment, they were able to deliver an hour of a half and then there's a rancher. And what this rancher did is basically search for 15 to 16 digit numbers on the American search

and then once it's found it was copied into the file and it was in the heart of the market and it was on other searchers. And I wish I had my clicker because I've got really cool pictures. So once they were able to get these copies of these numbers and hide them,

what became really neat and really sophisticated about the attack was the exfiltration method. How do we get that data out of the target department and get it into our possession? And so what happened is there's a communication program called NetBios which allows for systems to talk to one another to talk to one another and they were able to take advantage of that

and exfiltrate that data inconspicuously among normal traffic and so that data left Target's environment to compromise their use all over the world. And once it was completely out of Target's environment, they were then able to take possession of their service. And once they did, well, that data actually saved them.

And once they took possession of that data, they were able to survive. That's how they could survive. So what's the key takeaway? What's the lesson? And the idea is, again, it goes with perspective and mindset, is to secure assets and not programs.

We still talk to companies every day, close to 500 companies, that are hell-bent on securing their program. Right? That's what we want to do. Put a chain link that's up around that barbed wire, whatever it is, you have to protect it from the perimeter.

And, unfortunately, that's an antiquated way of doing things. Traditional defensive methodologies defend against traditional attacks. And traditional attacks. And traditional attacks come from either people-focused, either a digital or remote attack, or a physical attack on the infrastructure itself,

going against the server, whatever it is. Traditional defenses, of course, employ training for your employees. You see training all the time. Training is a gift? Defensive products, firewalls, IPSs, those types of things.

We also see, of course, security guards. You see security guards on the outside of the building here. You have all of their offices downtown. Security cameras, things like that. Those are all fairly decent options for traditional attacks. Unfortunately,

modern attacks are people who get them. Modern attacks use a growing number of attack vectors and systems, integrated vendors, things like that. So, as illustrated

in Target, in the Target example, you had an attack on Target where they used the defender of Target to not only get access, to also deliver the malware payment. So it's really, really interesting how they did that. So how do you defend against it? Well, scaring assets, not defenders, by building layers of defense did that. So how do you defend against it? Well, by building layers of defense against debt. It's really easy in theory. You want to lock down your most high value assets first

and work out the future. That's the main thing. So whenever we go into, or any good security plan will go into consulting engagement. The company is all about where are your assets? How valuable are they? Why are they valuable? Who wants to go after them? Let's build a level. And then let's lock down the assets. And you really want to operate under the premise that the bad guys are already there.

You already lost the war. You already lost Australia. The bad guys are already there. So you have to operate under the assumption that you can no longer defend your perimeter, that you can defend your assets. And that's what we have to pay them for lots of money. It's not just about IAC. Sometimes, if it's tough, I'll talk about IAC,

but it's really in good security mode. It's going to talk about assets and operators. Second thing we're going to talk about, and this one is actually really, really interesting because I can't tell you who it is. It is a global chipset manufacturer. You guys use their product every day. And they came to us.

It's a really interesting story. But they came to us, and they needed us to take a look at their newest security chipset. And what was told to us was, I want a black box penetration test. And our response is always, when we hear that, what is it that you really want? What are your goals? And the goals are always, well, I want to figure out how to be most resilient against the outside attack. How can I really protect the assets? And so our response is always,

what you really want is a white box with abilities. Your goal is harmonized with a white box with abilities and not a penetration test. And it's kind of interesting because there's been a lot of anti-U of A regarding these terms. And there's been a trend

over the last couple of years of how many of them we vote, we get a black box penetration test. We see the request all the time. And when we have those conversations, we always try to refocus the customer and try to really determine what his goals are.

If you just need to check boxes, then you can get a black box from the treasury desk, you can have someone else do that. But if the idea is to actually become secure, then what you want is a black box. The liability assessment, the company's black eyes can help you with that. And so it boils down to access level and evaluation types. Has everyone in this room seen this? Are you familiar with these terms? Most of the people in here?

So I'm not, okay. So it basically boils down to access level and evaluation types. In a black box evaluation, the investigative entity has no inside knowledge of the product itself. All you can gather is what's publicly available. And you go at it like a complete outside. In a white box access, we have access to engineers, developers, C-suite guys, we have access to software, design documentation,

everything that you could possibly want in assessing a product or a system. And then you have evaluation types. And a penetration test is pretty much binary in nature. Can I or can I not reach differences? And a vulnerability assessment is completely different. And it works

to identify every single vulnerability and provide mitigation. That's the way. So the YBOX vulnerability assessment you have that assessment. Everybody in the organization is looking for every possible you have that assistant. Everybody in the organization,

and they're looking for every possible vulnerability for that assistant. Then only then can you actually make an action. Has everybody heard, has anybody heard the CASL analogy, is it relates to security in a church's house? Has everybody heard, has anybody heard the castle analogy? Is it the rest of the security in the church house? Alright, this will be fun. We talk about this a lot because it really illustrates the point,

it really illustrates the differences between black box and white box work. Security firms typically will migrate one way or another. Some security firms only do black box work. Some security firms only do white box work. We're one of those that only do white box work. We're going all the way. And so this example is a king that wants to have a security audit from his cousin.

He wants to know how secure his assets are, which are basically himself and his family. So he calls in his cousin from 13 years away. He has his cousin bring in all of his knights to perform the security guard. So cousin shows up and starts looking at the castle and he says, well, I see that you have a drawbridge, I see that you've got a moat, I see that you've got alligators in the moat,

you've got archers in the turret, you've got guys on the top of the hot oil, you're secure. Right? There's no way you can reach the next one. And so, later that night, the king goes to bed, tells his personal guard to stay in his nice door, don't worry about me, I have this awesome security on it, I'm good to go. So the next morning, the king is dead and his head is chopped off.

Well, so how did that happen? Well, it turns out that if you look at it from a completely different perspective, you would find this egress point that no one knew about. So that egress point is a secret tunnel built from the passage of this building so that the king can escape in times of siege. And maybe he knows someone else that will talk to him.

Right? Get that over, probably find a way in. So the ego's point to be repurposed is an ego's point. So when we contrast that with what would happen if the king had ordered a white box in their building? What would have happened? Well, the king would have obviously probably still invited his

peasants to come all the way and all these nights but he would have also had a meeting with the architects the designers the guys that actually built the castle probably his own team and he would have also divulged

he was so with all of those people are on the table, all of those minds, all of those different perspectives, you would have had a much better idea of how secure this hassle actually was. You would never know this with black box work. And as it relates to this, just because you're doing an assessment, just because you found something does not mean that you found everything. And just because you found

nothing does not mean that something is perfect. So the only way you have a way to find everything is to use the right perspective, find everything this is the right perspective the right mindset, the right methodology so going back obviously I can't mention your name

but through a series of discussions we decided to split the work and it's a really important company, it's a great gig for us, we want the work. It's a really important company. It's a great gig for us. We want the work. But we also want to do this test of what it looks like

side by side. What it looks like to do half the work from a black box perspective and half the work from a white box perspective. So they agreed after many months of back and forth to split the work. And so we had equal distribution of resources.

We had a team internally, kind of our best hackers, take on the Black Box portion. And then we had more of our computer scientists and cryptographers and those types of guys take on the White Box side. And what we found was really, really interesting and it provided an unbelievable amount of value

to the company. And so what we found again, equal distribution of resources. We worked on the black box two months, two hundred hours and we found four potential issues. And two of those issues were issues that the company already knew about.

But due to the nature of the assessment for the black box, it didn't come. So it was a problem. Another issue that we found was a mistake on our part. We did not fully understand how this is important. So once we presented it to them, we discovered, oh, yeah, it is much more important. That is what it is.

This is not easy of only the ability. And the last issue was a confirmed vulnerability. It was a high level. It wasn't critical. And on the other side, the white box, again, the distribution of resources, saying over guys,

two months, 200 hours, what we found was in the first two weeks, we found seven critical vulnerability. This is something that's about to be released to all of you guys. And we found seven, in the first two weeks, we found seven critical vulnerabilities. So we called the company and we said,

Hey, here's what we've found so far. How do you want to continue this? And so what happened was, we ended up taking our team and embedding it with their headquarters. And working alongside the developers, the engineers, giving them source code, having better access to design documentation, everything we could possibly want.

And at the very end, we found not only 21 confirmed vulnerabilities, but I think a lot of the 12 were critical, we also were able to provide 21 mitigation strategies for every single issue that we found. As opposed to the lockbox side, there are no mitigations provided for you. That's up to them to fix.

We want to acknowledge those who provide test mitigation strategy. So over here they spent 200 hours to find a problem. Over here they spent 200 hours to find 21 problems and also 21 plus mitigation strategies.

Extremely valuable to the client. Routers. And I'm trying to move through this fast usually it's about an hour and five minutes I'm trying to make this 40 to 45 minutes it's a fair way of thinking and it's not also a word so this actually was

this work, all of these breaks came from our research division. And one of our guys came to us and said, hey, I've been fiddling around with small office-time office routers, and I'd like to turn this into a research project. I think there's a lot of valuable information here. I think we can do a lot of good with it. I think there's a big story to tell. We said, OK, that sounds good. We allow our employees probably 20% of the time to pursue research projects that they're passionate about. They're big on security. So as long as what we get out of it

harmonizes with either the mission of the company, the education of the employee, or benefits of our clients, we usually bring a lot of these projects in currently. So what we have is, it came to us, and we gave it a go-ahead, and it totally go-ahead by, let's say, 10 of the most popular small office home office rents. These could be used in companies all across America, in homes all across America. They're used in hospitals to transfer data that should not be running

across these networks. They're used everywhere. And so what we found after a few months was that after initially Greenline 10, we actually bumped that up to 13, but we broke every single one. Initially we thought, if we break bumped that up to 13, but we broke every single one. Initially, we thought, if we break three or four of these,

that's something to talk about. We could produce a white paper on it. We could initiate some people. But we broke every single one, and they were all susceptible to either remote attack or local attack with both. And what's interesting is this. You know, you think, okay, well,

we all know routers are vulnerable, right? I mean, router hacking, we all know that they're vulnerable. But the depth of the study actually led to the Electronic Repair Foundation getting involved in it. It actually led to the first IoT village in DeftCon this past year. So a lot of good stuff came out of this. A lot of recognition for how crappy of a job most of these companies do, shutting these drivers out the door.

As we look at it, it's really about functionality and it's not about security. And it's not really their fault. I mean, these are for-profit companies. This is what they do. So, real quick, so this guy is a bad guy, and this is obviously a home office

somewhere in California. Most likely San Diego. The beaches in Austin, I mean Texas, look nothing like this. So, it's all in Texas, look nothing like this. So it's all seaweed and shells and things like that. Over the go. So this is a bad guy.

Let's just say he's in Romania. That sounds good. And so in order for him to perform a remote attack, he has to have some involvement by the staff. Whether he navigates to an insecure page, whether he's a victim of a spirit issue campaign, whether he puts on an ad on Yahoo, which is obviously a malicious ad in Yahoo, which I'm sure

you guys remember over the last couple of years. That's been done many times. Not so much anymore, but one time it was a big problem. And so once he gets that guy to navigate to a certain page, he can download malware, download some scripts, and then he has that malware. And as far as, let's see this one. That works.

Perfect. I'm going to leave this here. And so a local attack, while not as sexy, is actually quite a bit scary. Because it involves no involvement on your part. I'm sure everybody here has gone to a Starbucks example of a time, or some coffee shop, and connected to the network. This is actually really, really simple.

And what happens is, and it does require their physical presence. So this part is true. But a bad guy can walk into a coffee shop, and he can connect to the Wi-Fi network. And with some simple tools, he can figure out exactly which router is powering that network without Wi-Fi connection. And once he discovers that, he goes online and he looks for known exploits for that particular router. And these are exploits that are reported by companies such as ours. Although we do

go through the process of responsible disclosure and we do provide the initial strategies as most research firms do for the manufacturers. You can do a certain amount of time to fix it. Here it is. Here's what you need to fix. Here's how you need to fix it. You can put it on a silver platter. A lot of them don't. But, you know, we eventually go to press and we talk about all this stuff. So that guy can go online, figure out exactly what type of exploit he needs. He can download the link on the description and follow the traffic across that. And then he can push you to the other pages to do that one day. And then he gets all of your credentials for any of the sites that you go to, such as online banking or social media, whatever it is.

Once they do that, they own everything. And it's very, very simple. And the message here, the key takeaway, is this idea of security versus functionality. So many times today, companies, again,

these are for-profit companies, and it's all about the money, are quick to companies, again, these are for-profit companies, and it's all about the money, are equipped to let functionality show. The more functions my particular router has, probably the more routers I'm

going to sell, the more money we're going to make. And a lot of times these things shut out the door going to make. And a lot of times these things are shut down with the word bar too fast. And so functionality basically rules over security. And not every router company is like that.

There's actually some really good ones. Asus does a great job with this. They always respond to us on time. They always want to talk to us about issues that we found and how can we fix them. They're great. Who was that?

Jesus. And if you walk in and rush over to our analyst house, you're probably going to get a decision. The problem with that is they also ask you to confirm where you're going to take them to the region. There's some of that. When you take a bunch of analysts and they're all behind the same route,

it's because they can do things that most people can't. But from a foundational perspective, they're pretty good. And they're really good at fixing things. So, you know, everybody has their faults and their faults, but they actually respond to more than they see. So, you know, yeah, everybody has their faults and their faults, but they actually respond more to things. So, we like that. And so, one of the problems

with it is this embarrassingly oversimplified corporate structure where security and functionality bow and bow, and they report to IT, who then reports to the C-suite guys. Right? Well, the C-suite guys, they want product out of the door. And around the world, it's not necessarily

the most secure thing. It's how many people get out the door, the most amount of features, etc., etc. And what a lot of security firms advocate is you have to break that up. Conflict is good. We want conflict,

right? Because the priorities of these teams are extremely polar opposite. So we want IT security flowing up to security, who then reports to C-suite, the functionality

reporting to IT, who then reports to C-suite. And like I said, conflict is good. That's what we're going after. And this is best illustrated by a story regarding a company that has no CFO. And let's just say

that the CFO, chief marketing officer, wants to go to a trade show. And he decides that this trade show is going to have all of those customers there, potential customers, and he's going to spend $100,000. Well, without a CFO, who's going to tell him that? How do we know that that's spending a couple of dollars?

So if the CFO is all the same, he's going to say, wait. Let's talk about this. So we can simulate a guy. He's an investor for the company. And it shows. So perhaps that $100,000 is a good time. Perhaps that's what we need to say. Maybe we need to say more.

Perhaps it's less. But at least there's a dialogue occurring about what the best thing to do is to have these conferences. And so, conflict is good. And we go back to priorities. The priorities are functionality and security

are completely different. We have delivery deadlines and performance, which all relate to functional priorities. On the security side, we have access control, defense in depth, things like that. When they're between the same teams, we have the same people, who's responsible for securing functionality.

Almost every single time functionality wins today. Because the conflict actually undermines the objective when it's within the same team. But it's beneficial when it's between

the same people. You facilitate dialogue. You discover ways to actually make something better, more secure, Snapchat. Snapchat. Anybody remember this? So, that's when they were hacked. I kind of like that picture. So, yeah,

so Snapchat got hacked. And I'm actually going to spend very, very little time on the hack itself because it's probably the most boring hack, but it really illustrates a very, very important part. So what happened was, Snapchat designed to roll out this feature called Add a Friend. And there's this thing called rate limiting that comes into play here.

But basically what happened is with Add a Friend, you could get Snapchat access to your phone, permission to access your contacts. It looks at your contacts, it looks at those contacts and then it spits back all of the ones that haven't been database-backed on Snapchat. At that point in time, you can say, well, I got that right. How did I not know they had Snapchat?

Well, what a bad guy does, because rate limiting doesn't exist, is he just uploads the whole upload for San Diego or LA or whatever it is, and he sends it off to Snapchat. And Snapchat reports that, hey, here are all of your friends that have Snapchat. Who doesn't know you? You just open a Snapchat account for an emergency.

So at this point in time, he's got all of these Snapchat users. Now, he's got a name. He's got the phone number. So he could just be ignored and called and he'd print calls and things like that. But he could also, as you guys know, probably use the same ID for different websites, right?

Or whatever it is. Banking, you know, whatever it is. Banking or social media or whatever it is. So what he could then do with that data is start leveraging that data to attacks on other sites, whether that's social media or banking or whatever it is. So it gives him, you know, and it was a bad deal. They just, Snapchat just threw it out and said let's just see what happens

and so the lesson in this is to build it in not bolt it on and Snapchat really didn't they didn't build it in they really didn't bolt it on

they just released it into the wild and that particular attack could also could be leveraged in other ways on the phone and get access to other parts of your phone that most people haven't really spoken about

so it's really more serious than I make it out to be but build it in versus bolt it on. And what we see is this idea of whenever you have a bug or a security issue or something like that, and the requirements, design phase or implementation, those things are incredibly easy and cheap to fix in that stage. If you try to fix a design bug in deployment, it's incredibly expensive and sometimes impossible. If you have to fix a security bug that arose out of some bad source code

and you're trying to fix that in deployment, it's incredibly expensive and sometimes impossible. And so when we talk to clients, we don't do any good security protocols to clients. We hear a lot of times, well, I don't have time to do that. I don't have the time to do that. I don't have anything I want to do. We're trying to build a project. We're trying to do this.

Whatever the excuses are. We've got timelines. We've got deadlines. We don't have this out by next quarter. Whatever the reason is. Our response is always, you have the right people together right now. All you need to do is ask a few more questions. It's just a few more steps.

It's not like we're asking you to move down the wheel. We're just saying, hey, just take this one step further. For example, in requirements, where you're determining the needs of the business, why are we building this, how are we going to build it, how will our customers benefit, start talking about a threat model. When you're in implementation, you're developing code,

from a security perspective, how do you code on it? Really simple. It's not that complicated. In testing, that's when you would want a vulnerability assessment performed. In deployment, you have configuration guidance.

In maintenance, you have iteration learning. So there's a way to do it appropriately. If you build it in and start with security as a foundation of what you're trying to as part of the foundation for what you're trying to accomplish in the beginning, it's going to be far more effective and far less costly

to do it that way. And so when we were coming up with this, we said, well, why don't we investigate our past work and see what those numbers actually are? We were asking companies to make a financial commitment up front that they may not have

originally thought about. And so what does that mean from a financial perspective for the company? So what we found was that if you engage a security firm, and this wasn't just us, if you engage a security firm in the very beginning, in the requirement stage, it's about 10% cheaper than just having someone come in at the end of the bill and bring it to the board and do the security assessment. So it's already cheaper. The real value comes in when,

what does it cost to mitigate the issue? And what we found was, at the end of it, when you want us to bolt on a solution to the problem that you've created, it's 25 times more expensive to do that for an application.

It's 300 times more expensive to do that for an infrastructure environment. So what would have cost us $4,000 to fix in the beginning now costs us $300,000 to the application

so it's incredibly more expensive to fix and it's not nearly as effective last thing is the iPhone I talked a little bit about the iPhone in the beginning is the iPhone. I talked a little bit about the iPhone in the beginning. I'm trying to probably do it on my own. So, the iPhone. What, you know, the iPhone first time, of course it changed everything, right?

We have the power of the world in our fingertips. We kind of had that with the Trio and some Blackberries, but the iPhone really changed everything. Browsing the internet was a wonderful experience with the iPhone. And industries, whole industries built around this particular device. So when it came out, we wanted to be the first company to bring it. Just because it's a better app. We thought it would be cool if we were the first ones. So we started doing some research in the mobile browser functionality of the Apple desktops.

And what we found is a few weeks before they released the iPhone, there was a vulnerability that was discovered in the Safari browser. And so we thought, for sure there's going to be a version of that browser ported over to the mobile device. And sure enough, there was. And so what we were able to do at this point in time was write a buffer flow attack that enabled us to take control of the phone. At the time, we had a New York Times columnist

embedded in this project, and we were able to, from our offices in Baltimore, take control of this phone, get administrative access to his phone and we were able to send text messages, send

email, manipulate pictures, operate this camera, change all of these contacts from our office to this phone in New York. So the lesson, and how do we keep things from happening like that? And Apple's, I think Apple's pretty good listening to security firms when they find issues. But this idea of security is an ongoing process. Again, it's a mindset, it's a perspective, right? The mindset has to change in order to deal with how modern attacks happen.

And when you have security as an ongoing process, what we see here, this chart right here, really illustrates feature proof. And I'm going a lot faster than I usually go to try to finish this up. This is feature proof. And as we know, all products, all systems, iterate over time.

And typically those iterations create new attack vectors. It's not a one-to-one ratio, but typically new attack vectors are released when products are iterated. And so what typically happens in the security world is these long period of review cycles where a company comes in once a year

and performs this assessment. We've seen the cost is actually cheaper than it would be more often, but this is what a long period review cycle looks like where this is when it's secure when you have an assessment, and of course, these are when you add new features and it becomes insecure.

And what companies are more and more proposing are quarterly review cycles. Where you don't have a company come in once a year, you actually engage that company throughout the year and they do quarterly assessments. Now you might ask yourself, well, hell, if I can't pay for four, I mean, for one, how am I going to pay for four? And the answer is it's actually cheaper to have a security phone engaged throughout the entire project, throughout the entire year, than it is to have to come in once a year and perform an assessment. And the reason for that is, just like you guys, if you got an economic project and they told you to come back a year later to be at the same proficiency level, it takes time for you to do that. You have to get re-evaluated to the project, to the code you're using, to what the purpose, the original purpose of the build was, all that kind of stuff. So what we find is that when you allow a security firm to work with you

over the whole course of the year, it actually gets less expensive every time. And not only that, but you're able to call your security firm or your security team, whoever it is, and actually have a conversation. When you're about to release a new product. When you're about to release a new product,

when you're about to release a new feature on a particular system, that you can actually have a conversation with your security team and say, hey, what are the ramifications of this? What happens if I do this? And most of the time, the security team will be able to answer that question on the phone.

Maybe they have to hang up and think about it for a little while. But you'll get an answer, question on the phone. Maybe they have to hang out and think about it for a little while. But you'll get an answer and you can proceed. And you'll have a much more secure product with that feature. So going back

to the cost and why is this cheaper? Well, when a security firm is engaged over time, it takes a lot less effort on their part to basically do those assessments. Teams already have the speed to write

and access all the sorts of design documentation. We just looked at it 45 days ago. So it becomes cheaper over time. In fact, these quarterly assessments are 20 to 30 percent, typically closer to 20 than what an annual assessment would be.

So you get four in the class of one. And you also get a much more secure deployment, not particularly product-resistant than it ever is. That's it. So I hope whatelessly Broken was the rather competition. You guys can look that up. That led to an engagement with the EFF and also the first I was involved with DEF CON.

A Mean Secure is what I'm actually working on. That's an 18-month pilot program where we're trying to figure out how to discover, how to defend possible losses. They're locally insecure. No one has really tackled it from the angle that we're tackling it.

We've got a lot of new people on our advisory board, Dr. Larry Ponemon. We've got Isis, who's from Texas. There's David Finn, who's the godfather of Cilentec. He's probably the godfather. And he's the VP of Healthcare for North America. So we're getting ready to release that study probably in the next 60 days.

I mean, it's not only going to be a study of the state of technology and healthcare, where we have some hospitals that have been in the program, as well as some technology companies, there's actually going to be a blue product that they're getting work to create. We're not charging them for the part. We need to get that industry to use

so that these hospitals can actually become more secure. It's going to be a really intensive effort for something that, as far as research goes, we've been already searching a bit a while. That's it. I try to wrap it up in 15 minutes. Probably 14 days to go. Any questions?

I'll throw a comment, Jim. During an agile process on, say, a two-week or four-week cadence, at the point where I'll throw one comment in. If you're doing an agile process on say a two week or four week cadence, at the point where you're starting up each sprint and you've done your user stories, that's the perfect time to get your security consultants or security team involved. If you've got written documents describing the sprint, they can provide feedback right at the beginning and that can be very efficient. Thank you.

Do you have any comments or other questions? Thanks for listening. If you have questions about the material presented in this podcast, be sure and join our developers mailing list by sending an email to developers-subscribe at sneha.org. Here you can ask questions and discuss this topic further with your peers in the developer community. For additional information about the Storage Developer Conference, visit storagedeveloper.org.