...Tangent. He apparently is somewhere else. I happen to be walking by.
And the illustrious group of, you know, representing, I guess corporate America is what you guys represent. Is that correct?
Okay. CISO. They told me they wanted me to go ahead and step up here.
If Dark Tangent comes in, I'll be happy to hand over the process to him.
But in the meantime, this is kind of a... I mean, I literally just walked by.
I have no idea what the panel is about or anything.
Something along the lines of CISOs, and they're going to discuss a number of things.
There's a few sample questions in the book in there.
I think one of the sample questions was how do the panelists feel about security research,
its impact upon the economy, impact upon the community.
And I think that's especially timely when you consider what happened at Black Hat with Mike Lynn
and the now former ISS employee being sued by a myriad of people, apparently.
So why don't we have someone up here on the panel kind of jump in.
You guys be thinking of questions, too, to ask these people.
Actually, first off, let's just go down the line.
You guys go down the line, introduce yourselves, tell who you are, and then we'll get to the question.
Does that sound okay?
Just name, title, and IP address of your VPN.
Just to...
Qualifications.
Yeah, qualifications, too.
So I'm Justin Semeny.
Obviously, I have everything I can do.
Wow.
It's not working.
I'm Justin Semeny from VeriSign.
So I run information security.
That's it?
Wow.
Qualifications.
What's that?
Qualifications.
He's not qualified.
Pamela Fusco, Chief Information Security Officer, Merck Pharmaceutical.
I'm certifiable.
Who next?
This one?
Yeah.
I'm Scott Blake.
I'm a CISO of Liberty Mutual Insurance Companies.
My background is I was the VP of Information Security at Bindview Corporation.
A couple ex-Bindview people around, I see, founded the Razor Security Research Team.
And so I obviously have a bias for very much in favor of information security research,
particularly basic research around vulnerabilities.
I think it's essential to improving the technology that we have to work with as part of the businesses that we're trying to operate.
So I'm all in favor.
Hey.
Hey.
Sorry, I'm late.
I've been distracted by other business.
I've got these slides up here, but I...
Doesn't work.
Doesn't work?
Doesn't work.
So you got through the introductions?
No.
Still going?
Oh, okay.
Thanks, Pam.
Proud to serve.
Hi, I'm David Mortman.
I'm the Chief Information Security Officer for Siebel Systems.
Most of you have the pleasure of having your personal information in one of my systems at one of these people's companies.
So that's why I'm here.
I'm Ken Files, CSO, Capital IQ, a division of Standard & Poor's.
I'm Andre Gold, Director of Information Security for Kynan Airlines.
And I'm Paul Simmons, CISO of ICI, and I sit on the board of the Jericho Forum.
I think people were asking... you were asking about qualifications.
The only qualification I hold is I'm a qualified whitewater canoe instructor.
Okay, sorry I was late.
Typically when we... we've tried this in the past.
I had all these really nice questions and tried to get them off on certain topics.
And we didn't have a lot of time for questions and answers.
So this time I'm going to try something different, which is a lot more audience participation.
I have a couple of questions for them first.
And then we're going to let them talk about it for a while.
I only have two or three.
And then we're going to open it up to the general audience.
And then my job is just to make sure that if you ask like a 30 second question,
I'm going to distill it down into like a four second question.
So keep that in mind.
Okay, hey, so question.
Would you hire hackers?
How does the word hacker influence your hiring decision?
Or are you purely concerned about criminal backgrounds?
I mean, if somebody comes to you like a hobbit and says,
I'm a self-described gray-bearded Unix hacker,
whoever's got the most serious feelings about this?
Well, I've hired a lot of hackers in my time.
So I am very much in favor of using hackers.
And I use the term really in the old school sense.
I mean, we're talking about people who break things for the purpose of knowledge,
who generate new knowledge about systems and software and what have you.
And that's essential for doing security research.
However, I would also add to that,
that I would not ever recommend hiring a criminal.
Now where the line gets drawn is sometimes a little bit fuzzy,
but that may be a whole other discussion.
I mean, would you do a Google search on their hacking handle
and see if it pops up on some Chinese defacement team?
I would definitely look at published research that somebody has done,
and look at what participation in discussion lists,
whether they've contributed positively to the community or not,
and if there's somebody who has respect to their peers and so forth.
I would not intentionally dig deep into other activities
beyond those positive contributions to the research community,
other than a criminal background check.
I've hired people who've gone bad.
So they were good when they came, and then they went to the other side.
And the other thing is, I would do a Google search...
Was it because they were reading 2600 or something?
Because I'm really tough, man.
No, and the other thing is, I would do a Google search,
but if they're good, I'm not going to find it anyway.
Yeah, I don't hire hackers. I hire intelligent people.
And if the two kind of correlate to each other, then so be it.
So you think this whole debate about hiring hackers is a non-issue, pretty much?
I've got a 13-year-old daughter, so I'm pretty much well-tuned with that.
There's a media misconception, I think that's out there,
that hacker correlates to criminal.
Which I think most of us would hopefully agree is wrong,
that there may be certainly examples of correlation,
but that doesn't necessarily prove the rule.
It's sort of like a plumber, right?
You can have a plumber, or you can have a criminal plumber,
but they're still basically a plumber.
So yeah, you can be a criminal hacker, or you can be a...
Yeah, over in the UK we have a thing called check certification.
I don't know if anyone here is check certified.
Basically what it means, it's the only certification, as far as I know,
in the world for hacking.
And it's actually sponsored by the UK government.
And it means that you're cleared to hack UK government systems.
And that means they've done a background check,
and they're happy with you working on government systems.
And personally that's good enough for me.
If you're check certified, I'll hire you anytime.
Anybody have any questions or comments on that?
Yeah, you in the red, please.
So the question was, there was a presenter at Black Hat who was fired for giving his talk.
And he quit two hours before his talk, apparently, but he wasn't fired.
But had he not quit, he would have been fired.
And the question was, would somebody like that have any hiring prospects
at companies represented by these types?
I'll answer that.
Yes, I would hire him.
Because I don't consider him to be a criminal.
I consider him to be someone who has brought something to someone's attention.
And he's gotten quite a bit of attention over it.
But I think that we all learn from what has happened in the past,
and I hope that we move forward.
So I think that he's a qualified individual.
And if I had a position and he passed the HR criminal blah, blah, blah,
he would be gainfully employed.
Anybody else?
I just second it.
Insofar as there was a call for security research.
I don't currently run a security research team.
But if I did, then sure.
With the same caveat.
I think there's another question over here.
Sir?
What are your peers up to?
Are they hiding from this issue?
Are they indifferent?
I think it's our responsibility to bring security to their attention.
That's what they pay me for.
And I'm lucky in that respect.
I get quite a bit of support from the executive staff.
And I think that they would trust the opinion of what I'm bringing to the table.
But I also trust, it's not just me, it's my team.
And I have about five people in this room that come with me to Black Hat and to DEF CON.
And I trust them.
And if they're, you know, they're going to be working with these people.
I just sign the paperwork and pay the bills, right?
So if they're in agreement that an individual such as that is welcome on the team, I'll be damned.
Then I'll take it to the highest level I need to to get the person hired.
One more question, we'll move on to a new one.
Sir?
I'm sorry, talk a bit louder, please.
Well, that's a broader question than whether or not they're going to hire hackers.
It's a privacy question.
We could ask them about the Patriot Act later, that's not a problem.
But is it a hiring a hacker related type question?
What's that?
That has violated the Patriot Act?
It's being done every five seconds.
I mean, plenty of people are hacking every day and they're not being busted on the Patriot Act.
Okay, so let's move on to the next...
Oh, do you have one more question, sir?
Right, right.
And I think there's a question on this earlier.
His question was, how do you rate private versus professional experience?
Versus maybe academic security experience?
And weigh that in a hiring type decision?
And it also kind of relates to what we talked about earlier, which is certification.
You know, would you hire somebody with a CISSP or a security MCSE over somebody with nothing?
So, from my perspective, actually, work experience...
Would you turn it off again?
No, you have to be really close to me.
So the work experience actually means a lot.
When we get specific down into the skill sets of actually hacking or breaking applications or breaking OSs or networks, etc.
I agree, there's not really a lot of corporate jobs that you can actually reference on a resume in order to prove those skill sets.
A lot of that actually just comes out in the interview process.
You break them down and be able to say, how would you do X, Y, and Z?
Or what is your mentality or thought process going through an actual attack?
And making sure that it's mature and it's done in a well-defined manner.
And it's not a script-kitty kind of attack.
It's actually very well thought out and very detailed.
I mean, so just to expand on that a little bit.
Degrees, certifications, they hold their place in a sense that you have concepts as well as degrees.
And our organization as well allows for mobility up that corporate ladder, so to speak, as well.
But when I'm out there like Pam said and everything else, looking to bring on people to augment my staff or respective duties and everything else, it's all about the experience.
I mean, the degrees and those type of things, they're okay, but they're kind of like the last thing that I look at.
It's like, okay, where has this guy or girl been?
What have they done and what can they bring to the organization?
Half the people in my team don't actually have degrees of any sort.
I think they have high school degrees probably.
Work experience is more of a metric for getting the resumes onto my desk than for actually as a hiring metric at that point.
More important than actually even experience for me and my team is just getting the ideas.
I can teach them the technical skills they need to have.
I can teach them the project management skills they need.
But if they just don't get it, they don't get the idea of security, they don't get the idea of risk management,
it doesn't matter if they've been doing this for 10 years or if they have a PhD in computer science.
I don't care.
Getting this back to reality, the bottom line is when you're faced with 600 or 800 CVs on your desk
or certainly going through a human resources department,
you go degree, no degree, degree, no degree, degree, no degree.
Ultimately, a relevant degree says that you are capable of a certain degree of learning.
And yeah, absolutely, you bring them into your business and you teach them
and you put them on training courses and everything else.
But the degree says at least they have the capability and the wherewithal to go out and learn new skills.
And it might not be perfect, but it is generally a fact of life in the corporate world.
The other qualification I tack onto that is publications.
For someone who's going to be doing research or red team kinds of activities,
I would want to see published new vulnerabilities or published papers on techniques, things like that,
as part of the qualification, seconding the other things that have been said.
Degrees do count, unfortunately.
I think one thing being left out of the equation is attitude also.
If you've got the worst attitude and you're the best hacker, I don't want you.
If you can't play well with others, I don't want you.
We'll have one last question and then we'll move on to a new topic.
I think you've got to let them devote a certain amount of their time.
I don't have my folks doing 100% of their focused time on one particular task.
I let them work in different areas of security.
We provide them with the training that they'd like to go to within reason.
Those are just a few of the things.
We also do peer training and sit-downs, lunches, outings, that sort of thing.
Send them to DEF CON.
Thanks, Pam.
Next topic is kind of near and dear to my heart, related to the whole Enron case, and that's data retention.
In the wake of Microsoft, how long do you keep data?
Do you do it as a defensive measure against lawsuit, or is it just sheer log bloat?
What's your overall thought on log retention, data retention?
Anybody?
I'll jump in here.
Log retention, or data retention more specifically, can actually be driven more by external legislation.
Be it credit card information, personal information, et cetera.
So there's a lot of limitations and requirements on how long we have to hold it and when we actually have to delete it.
Outside of that, the perspective is basically, on a yearly time frame, we go through most of the data.
The main reason for keeping the data is not only providing a service from the application side,
but it's also being able to go back in time for issues like litigation.
So would you say a year, six months, ten years?
I would say about a year. There are certain things that we have that definitely go beyond that, but about a year is pretty much the baseline.
Unfortunately, we delete data a lot sooner than that, unless there are regulatory requirements around that data.
Data has proven to be a liability to us as well within court.
And so our legal department actually comes down and mandates that data over the 60 days actually be removed and be expunged from the environment.
Our data retention policy is about 80 pages, and it's driven by a wide variety of state and federal legislation for different types of information.
And there are a lot of different things, and everything has its own rules for how it gets...
So it's a total nightmare mess.
I wouldn't call it a nightmare, but it's complex.
Yeah, I mean, we're driven by legislation, and we've got places, because we're a chemical company, where we have to keep data on people,
and particularly their state of health, for ten years after they die.
So potentially, that's up to 100 years, which is a real issue because, of course, media changes the whole time.
Media doesn't have a 100-year lifetime.
I was going to say, you've got a lot of money in MacStore and Hitachi, then.
We're going back to microfiche.
Microfiche is about the only thing that actually works properly.
Okay, sir.
The question is, how many of you have assigned policies dictating how long you'll keep the data?
Signed policy?
Yeah, signed policy.
Everybody.
We keep data 100 years in the pharmaceutical industry, which is crazy, because when you store data 100 years from now,
the technology that we used in, like, you know, 1801, it doesn't exist in 2005.
I'm sorry, who's speaking now? Stand up, please.
Oh, okay.
So the question is, how do you secure that data once it's archived?
Do you put it in a big hole in the wall, or do you... hole in the ground?
Salt mines.
Salt mines.
Salt mines are really good.
Sunglasses?
Right, right. So now that you're storing data for 100 years or whatever, does it ever come in handy?
Have you ever actually used it for anything?
Ten years, but we were founded in 95, so...
I think the furthest we've had to go back is in the order of about 30 years.
We were founded in 1928.
What was the circumstance for that?
It was a health claim against us for a disease that they developed, and they blamed it on us.
It wasn't me.
It didn't... they didn't win it.
I don't know what the exact number is for us, but the company was founded in 1912, and we sell life insurance and have since then.
So, probably that far back.
General counsel.
Legal.
Pretty much everybody raise your hand if it's driven by legal.
Yeah.
If you could have your way, would you get rid of it?
No.
So you think it is in the appropriate position.
So that's totally the correct location for that. Okay.
Absolutely.
Yeah, the data retention policies dictate not only how long to retain, but also when to destroy.
So a lot of our policies are written in terms of the maximum retention period, not only the minimum required retention period.
And when you reach those maximums, you just purge.
Yep.
And hopefully that Stone Mountain place doesn't have your hands on their tapes, right?
They probably lost it anyway.
Do you think that the burden or the overhead impaired by performing these retention policies is a burden on the business function?
Yeah.
At ICI Corporate Centre in London, we have a 15-month deletion policy on email.
And basically we force our employees, when it comes up to 15 months, to actually sort it, go through it.
This is automated.
It puts it into a bucket and says, you will sort this.
And you're forced to go through and either delete it or put it into the archiving system, at which point you have to give it a title, a date, what it's about,
and when it needs to be deleted automatically.
But yeah, absolutely.
You can work on projects for three years in some cases.
So yeah, it's a real problem.
There are certain issues where we have internal monitoring projects to monitor individual activity.
And we actually have a very short retention for that data.
Obviously, there's a lot of personal stuff going through the network.
And we do have investigations that we need to go back a year to really see what the full activity of a particular individual is.
So that would be one of the cases that we would have that it would impede what we do personally.
From a business standpoint, I mean, really the federal requirements or the industry requirements on data retention that are applicable to us really kind of really has changed the business and how they perform the service.
So not really from a service standpoint.
Okay, I've got one more question.
Oh, sir.
So the question is, are there data privacy laws surrounding how you retain the data?
Do you have to keep it encrypted?
Rot13?
You know, how do you keep it encrypted?
The paper files are really hard to encrypt.
Rot12, its successor.
Yeah.
So you say microfiche, and then you physically have control of it.
And then you put it somewhere and hope it doesn't burn down.
So when you look at things like PCI, or Visa's MasterCard certification program,
where they actually require the encryption of credit card data.
Well, for the companies that do it.
We all do.
Absolutely.
Basically, going back to the point, I think the encryption of the actual data on the tapes before they're shipped out is very important.
The encryption of the data within the database is, even though they're running in production, like the credit card data, social security numbers, et cetera.
I mean, it's absolutely imperative that we do that because application security is getting a lot more dangerous nowadays.
And without it, it's just a recipe for disaster.
So from a data encryption perspective, it also depends on what the data is and where the data is going.
So there's encryption regulations.
Data in transit needs to be encrypted.
But in some cases, data at rest does not.
There's also, because we're international, different encryption laws.
Paris is different than what we do in Germany.
Location of the data.
There's no off-site storage in Germany.
And I may be wrong.
It may have changed.
But last I checked, it wasn't.
So we have to be very careful when we're talking about what we're doing with what parts of the data and with what region specific as well.
And which algorithms.
So Jeff's a little busy.
Sorry.
Yeah, there's some action going around pool two right now I needed to know about.
I'll chime in on that if I could, actually.
Pool two action?
No, not that.
I mean, I don't know if anyone remembers the quote.
I don't know if Bruce is here.
But it was, if you think encryption will solve your problem, you don't understand encryption and you don't understand your problem.
It's a great quote.
And I think if we look carefully, I have to disagree with Justin a little bit.
But if we look carefully at some of the issues where we look at how things are needing to be encrypted or whether they should be encrypted, look at something like backup tapes.
Backup tapes, it's a great idea to store them in an encrypted format until you need to actually restore from the tape.
Then you have a problem because you need to decrypt that information.
And now that, depending on where you are, I mean, if it was just a simple drive failure, then that's fine.
But if your data center exploded and all your key material was there, you have a major problem.
So where are you going to store the key material?
Well, the safe place to store it is with the tape.
So what's the point of that?
You've got your key taped to the tape.
And so you can be sure that you'll be able to get the data back off of it.
And the guy who designed the key system is retired last year.
Exactly.
10, 20 years down the road, how are you going to do that?
You look at some of the application things, especially encrypting data at rest in a database.
Something on that application server or database server knows how to decrypt that data or it's completely useless.
The problem then for the folks in the room becomes find that piece of software and control it.
It's sitting in memory. The key is sitting in memory somewhere.
Wherever it is. It could be anywhere.
It could be sitting on a smart card that's plugged into the machine.
But something knows how to get it.
Some piece of code on that machine knows how to decrypt the information that's in that database.
And somebody's going to be able to figure out how to get it off.
Well, I guess the point of the encryption of the tapes is not necessarily for protection.
It's not necessarily the encryption on the tapes.
It's more so protecting it when that data is in someone else's hands.
We don't put our keys on our tapes.
And it is a problem.
There's no question about it in regards to how you manage those keys.
For us, we've had a little bit of experience in the keys.
How we actually have a distributed model and how we actually put it out.
But yeah, to your point, there are some fundamental flaws.
But you really have to understand your use case for encryption.
And if you think encryption is going to protect you from everything, I absolutely agree.
You don't understand encryption.
Okay, this is the last one on this topic.
We can revisit it when we go to general questions and answers.
How do you deal with...
Right, so we talked about this briefly, but how do you deal with obsolescence?
Are you constantly updating your backup technology and taking all your tapes from five years ago and updating today's technology?
Do you go through this rev cycle every five years?
Do you decide it's time to re-upgrade everything?
Anybody?
I'll say it again, microfiche.
Microfiche is where it's at, guys.
We have seriously looked at it because we've got this requirement for 100 years plus storage.
We have seriously looked at the problem.
Do you do it in machine code? I mean, how is it machine readable?
Is it in 3D barcode?
No, we print it.
You print it onto A4 paper in our case, or letter paper in your case.
And you photograph it and put it onto these...
Right, and the printout is encoded in a printed format in what, a 3D barcode?
A giant full page 3D barcode?
Is it ones and zeros on the whole page?
No, no, no, it's their data.
If they filled in a form, we print the form and we microfiche it.
Oh, I see, I see.
Blow it up.
Well, I'm just wondering what my Microsoft...
So you're saying it's definitely not Unicode, right?
No, definitely not, Jeff.
So do you print it?
Yeah, I'm just wondering, how do you print Microsoft Word binary?
With great difficulty. Print it. Hit print.
And it comes out squiggle question mark space space dash.
No, we're talking the application Microsoft Word, the application.
You don't care.
Okay, okay. So it's in hex. It's in hex.
Well, the only reason I'm wondering is because years ago some guy sold an application that would 3D encode your application,
print it out on your Epson FX80 printer, and then all you have to do is re-scan it in,
and you would have incredible data densities, because basically each dot on the data matrix printer was, you know, one or zero.
And they were claiming this thousand-year thing.
With a basic algorithm, you could reconstruct the data whenever you wanted.
It has built-in CRC checking and redundancy.
But they only had it on floppy.
Yeah, okay.
They only sold it on floppy disks.
But the business doesn't care about storing the application. They only care about the data.
So the data gets printed out in a report, and it's paper or microfiche or whatever, and it's the data that gets stored.
So, okay. I'm just concerned that you have the data but nothing to interpret it.
You have people. It's in English.
Okay.
Right? You want to back up the...
I think we addressed this.
You know, a hundred years of data.
We've just gone through, you know, last year a recall on a product that we had, and we had to find all of the data.
It's a problem.
So we're not going to sit here and tell you that we have a cure.
I mean, you know, we have drug cures, but it's a problem.
You have to understand, again, this whole data at rest issue is huge because I don't think that folks realize how much data they were going to need,
what purpose they would need to recover it for, and when they would need to recover it.
So you're right. It's an issue.
Right now, for Merck, we have a lot of data that's paper-driven because we have wet signatures.
We have a lot of data that's not.
So it is an issue.
You have to figure out what it is you're going to do.
And I think part of it is what data you need to make assumptions.
Ms. Cleo's crystal ball, I say this all the time.
What data may I need to go back and look at 100 years, 15, 25, two months today, tomorrow, whatever, and how do I get to that?
And what technology is going to be there?
And that's when you really have to have your peering partners with your vendors and hope that they're cutting-edge solutions
because you work with them to migrate off of what's old and bring it to the new.
We try to do that with Microsoft, but anyway.
So you really need to have peering partners with your vendors.
Okay, new topic.
So if you had to rate the danger from hackers, evil outside influences that are like bored college students,
versus organized criminals, versus internal employees, how would you prioritize those three?
What keeps you up at night?
The inside employee or the Russian mafia?
Oracle?
Oracle keeps you awake?
Marianne's not here. It's okay. She won't kick my ass.
Till later.
No, seriously, internal employees, industrial espionage, and then outside influences.
For us, it's the organized crime, the internal, and then the hacker.
Any of you guys?
Yeah, for us, it's the outside industrial espionage, number one.
Is your number one?
It'd be the internal employee.
So it's internal employee and industrial espionage are your top two, and the outside hacker is pretty much in the grass.
Not to disrespect anyone.
Yeah, I mean, I made the comment at Black Academy, and one of the reasons why it's the internal employee,
because we don't necessarily have a culture that's conducive to actually permeating security within our fabric,
our employee base and everything else like that.
We've traditionally built applications predicated on three things, right?
Cheap, fast. You can build them cheap, fast, or secure.
You can have any two of those, but it's real hard to have all three of those attainable in any project or application that you work on.
And so we've traditionally done the cheap and the fast as a way to convince our business units that, hey, technology can add value.
Now in this day and age and everything else, going back and trying to get security development integrated into the SDLCs
and then just the methodology and mindset within the employees is somewhat of a challenge for us.
So when security vendors are selling all the new blinky-blinky products that are all focused to protect you from hackers,
that's not terribly relevant to what you want to buy.
No, you just call bullshit. Go with it.
Well, you know what, though?
I think that an internal individual that crosses the line is the external individual.
And who's also to say, not to say that the internal employee, the trusted employee,
I'm not pegging on you here, Dave. Sit in for him.
doesn't share that information with an external person on a chat board, right?
How else are they going to get it?
So I think, for me, it's one and the same.
But I just go to bed at night now because I'll be there in the morning.
Okay, well, I mean, I'll kick off with that.
I mean, we're a chemical company.
At the end of the day, you can go out and buy our product, our brand new product,
and you put it into a gas chromatograph and you can get a spectral analysis and you can go out and copy it.
It's very easy.
What is going to keep paying my salary and my bonus going forwards is what we've got in the heads of our scientists
and what's in our computers, what's coming next.
It's how we steal a march on the competition.
It's an intellectual property, absolutely, and it is key to our business.
So it might be totally trivial things like paint that you paint on and starts pink and dries white,
which is one of our latest tricks.
It might seem daft, but it's actually stealing a march for those people who want to overpaint their ceilings.
And it's selling very well at the moment.
And the competition will bring something out in the near future, absolutely.
So it's how you can get that edge on the competition.
And that's all tied up in an intellectual property, and ultimately that's what I'm there to protect.
How you do it, of course, is the whole range, because you've got Trojans out there, you've got hackers out there,
you do have industrial espionage, and we know we have a lot of that out there trying to steal those secrets.
And, of course, you've got the mafia and the organized crime coming on.
But they're sort of carpet bombing you, rather than trying to do anything targeted at the moment.
When they get bored beating up the banks and the gambling sites, maybe they'll turn their attention to us, who knows.
For me, my main priority is protecting our customers' data, whether that's on our site or other customers' sites.
So I'm spending most of my time these days beating up on product marketing and engineering, trying to get new features into the product.
So I spend most of my time dealing with audit.
Which is... yeah, it's a bit of a problem, actually, with a lot of companies.
Where we actually find a lot of our attention being focused in areas that probably, maybe, in our opinion, aren't necessarily where they should be focused on.
I mean, I'm a very big believer in audit, but some of the rules and requirements coming out of SOX are a little bit misguided.
Audit for audit's sake is not...
Exactly. I mean, there needs to be a purpose to it.
I mean, so when we go through and we do an audit, I mean, I would expect that we hit the source code.
We go through the entire application. We actually review it for true load testing, not just, does everybody have a password?
Which is important, too, but there's a lot bigger issues out there.
But as far as the culture within the company, I think awareness campaigns kind of get a little bit of a slack internally.
But it's very important to really consistently beat that drum of what's important.
Do your job. These are the things not to do, etc., etc.
My job is actually not to protect the company from information security threats.
My job is to understand the information security risks that the company faces, which is risk in combination with threats, vulnerabilities, and assets, right?
Putting those all together and educating our business leaders as to what those risks are, how seriously they should take them,
and to facilitate them making a decision about what is the level of risk that they want to accept.
Because ultimately, at the end of the day, it's a business decision.
Exactly. And we're insurance, right? We're in the risk management business.
We understand this stuff. At least we understand risk management in other areas anyway.
We would love to have better data, which would enable us to do more management on that front.
But in the meantime, it's more art than science.
And that's what my job is, is to try to present a picture of what the situation is to our business people so that they can make a decision about what to do.
Okay, I'm going to go to this gentleman over here.
Yay.
Yeah, we're leaving now.
I work for a private company.
He's going.
Yes.
Hey, I'm in the middle.
No, I mean, identity management, for some sakes, is pretty important.
I don't like to have people tell me what I should do when they don't understand our business.
Or they don't understand our infrastructure.
Or they don't understand a basic operating system.
I mean, a lot of the audit organizations aren't necessarily very technical in nature, and therefore can't really understand what the actual risk is on your particular environment.
Or actually how to do some of the artwork in regards to the multiple layers of mitigation that were implemented to protect, you know, your application or your OS or your network or whatever.
The identity management issue is, I mean, we need to be able to very clearly and concisely identify who has access to what and who they are and what they did.
And centrally, it's important, but it needs to be driven in the right way.
Right, and just to expand on that, too, you know, identity management is another one of those, you know, vogue topics within, you know, information security and everything else.
So the problem with identity management is that if you don't have role clarity within your organization, meaning that I, as Andre Gold, an employee of Cutland Airlines, gets access to X, our inner resource and everything else, it doesn't matter, you know, what identity management technology solution that you have.
I mean, there's business process and definitions that need to be defined at the role level before you can even think about, you know, any sort of federated identity management or anything like that.
Understanding the process, understanding the roles, understanding the application, understanding, you know, what a maintenance worker needs access to versus a pilot, you know, for my particular organization.
Understanding those type of things.
Can I take a question from the guy in the back?
What do you think the benefit is? Is there a benefit to your business or your company by being here?
For me, it's a benefit to my profession.
What I do during the day is my day job.
That's why I earn my living.
This is my profession.
My company doesn't sell security products.
You guys help me protect my drugs.
That's why I'm here.
That's why I send my staff here.
No, yes, I'm a pusher.
No, but it's true.
I mean, this is, you know, either way it's going to happen whether we're here or not.
So why not be a part of it?
I mean, we're sitting up here because we all understand and have bought into the fact security through obscurity does not work.
The problem is there's a whole lot of businesses out there who haven't tweaked to that yet.
And there's a large router company I suspect is in that category.
To add to that a little bit, I think, you know, hanging out with you guys for a few days.
I get just as much out of it, you know, if not more, you know, than you guys do.
Gentleman in the glasses.
Okay, so rephrase the question basically.
We hear about cyber espionage or espionage in general.
How realistic is it?
Does it actually occur in your industry?
Is it something that's sort of just made up in the papers?
And have you seen them progress in sophistication over the years from maybe old techniques to new computerized techniques?
I'm guessing that maybe Pamela's industry is pretty competitive.
And so maybe we'll ask her.
Well, in clinical trials.
In clinical trials.
Well, I ask her because she's in charge of a 24-hour response team.
So I'm not real clear with what you're asking.
The question is, does it happen in your industry?
And if it does, has it gotten better over the years?
Industrial espionage?
Yeah.
In the pharmaceutical industry, we are exceedingly competitive.
I don't want to say espionage doesn't happen.
And I'm certainly not going to say that it does.
Because it's a very thin line.
So, for instance, when you're producing a drug, it's exceedingly competitive.
It's very expensive.
It takes about seven to eight years to bring a drug to market.
That costs approximately $8 million.
However, the bang for the buck is, year one, you recoup about $9 million.
After that, it's profit.
So getting to market is the issue.
And there have been studies done where competitors have gotten to market with a very similar drug 30 days before us.
And we never reached the power curve.
We made great money on it.
Excellent, you know, it helped humanity, the community, whatever.
But it's the dollar value.
They just never made it there.
So it's time to market.
Was it espionage?
You know, hard to say.
A lot of speculation.
$800 million?
$800 million to develop.
$800 million return.
But you've got to, like, not every drug you make is a winner.
No, well, that's a thing.
I mean, that's why it costs so much money.
But the other part of it is, too, we're not getting on a drug talk here, but the other part of it is, for instance, when you're developing a drug, for instance, you know what Propecia is, right?
It's for all those guys that want to grow hair.
Originally, it wasn't meant to be Propecia.
It was a drug for colon cancer.
During clinical trials, which is why we have to spend $800 million to develop a drug, it came out that this particular drug that we were developing for colon cancer helped men grow hair on their head.
Hence, therefore, we got two drugs.
So, you know, a double whammy.
Yeah, kind of like Vegas, two for one.
The insurance industry is actually a little bit strange in that respect, in that we're required to file publicly much of our business information, rates, some degree of underwriting, and so forth.
So a lot of our stuff is in the public domain already.
And the competitiveness has a lot to do more with brand and reputation than anything else.
It seems to me as though the business people at our company always seem to know what everybody else is doing in the industry.
I don't understand exactly how they do that.
But it seems to be universal, even at other companies in the industry.
So I don't know if they all get together on the weekends or what, but I don't think there's a lot of industrial espionage taking place because of the sort of semi-public nature of some of the services that we provide.
So from a general perspective or an industry perspective, the amount of that particular crime going on has really stayed the same.
It's actually the methods that they're using in order to get the data out.
Very typically, it's the same old methods, conversations, walking out with knowledge.
However, when you start seeing things like data being embedded in images, technography, it gets very complicated in order to truly identify it while it's leaving your company.
But typically, it's just walking out the door within somebody's head.
Guy in the Sense Post shirt, I recognize your fine fashion sense there.
Does audit response belong in your organization? And if it doesn't, where does it belong in the hierarchy?
For us, it does. One of the things I own is IT audit.
The reason that we actually put that there specifically is because we wanted the skill sets and the control belief system to really be embedded within the person who's doing it.
We didn't want it filtering out into kind of a business unit or application kind of mentality when looking at the controls within IT.
So, yes, it's within our group now. I've seen it a lot of different ways.
Yeah, they focus on finance.
At what point do you kill a bad app that was developed internally?
Well, I think as a whole, our mission is security. So, I mean, that's kind of one in the same.
And as far as getting security embedded into the application in the first place, I think that's probably one of the hardest challenges that companies are facing today.
And getting that mindset established. You've got developers coming into the organization fresh out of school, didn't really teach them proper coding techniques, that sort of thing.
How do you get education into here? How do you get that integrated into the whole development life cycle? And how do you make that process repeatable?
Okay, well, we're actually out of time. So, I think I'll take one more question and then these gentlemen and ladies will be around.
And they'll be happy to answer your questions, hang out, buy them a beer, you know.
Okay, gentleman right here in the corner, yes.
And at the end of the day, your job is to inform the business decision makers so they can make an informed decision, right?
And you can't do that if you don't understand the business. You have to know, I spend more time in my job learning about how insurance works than probably anything else.
Okay, let's give him a round of applause. Thank him for coming up here.