Tuesday, January 08, 2013

Learn How a Telecoms Provider Takes Strides to Make Applications Security Pervasive

Transcript
of a BriefingsDirect podcast on how perimeter security is no longer adequate to
protect enterprise data that resides in applications, and how one services provider is taking a different approach.

Los: We're in beautiful Nashville, Tennessee, the home of Opryland and country music.We're sitting right here at HP Protect, from HP Protect 2012, Day 2.

Gardner: We have a fascinating show today. We're going to be learning how the telecommunications industry is tackling security,
managing the details and the strategy -- that’s both the tactics and the
strategy simultaneously -- to an advantage and extending that value onto
their many types of customers.

We definitely are at the time and place where attacks against organizations have changed.

With that, allow me to please introduce our guest, George Turrentine, Senior IT Manager at a large telecoms company, with a focus on IT Security and Compliance. Welcome, George.

George Turrentine: Thank you.

Gardner: I'd like also to point out that George started out as a network architect and transitioned to a security architect and over the past 12 years, George has focused on application security,
studying vulnerabilities in web applications using dynamic analysis,
and more recently, using static analysis. George holds certifications in
CISSP, CISM, and CRISC.

George, many of the organizations that I'm familiar with
are very focused on security, sometimes at a laser level. They're very
focused on tactics, on individual technologies and products, and looking
at specific types of vulnerabilities. But I sense that, sometimes, they
might be missing the strategy, the whole greater than the sum of the
parts, and that there is lack of integration in some of these aspects, of
how to approach security.

I wonder if that’s what you
are seeing it, and if that’s an important aspect to keeping a large
telecommunications organization robust, when it comes
to a security posture.

Attacks have changed

Turrentine: We definitely are at the time and place where attacks
against organizations have changed. It used to be that you would have a
very focused attack against an organization by a single individual or a
couple of individuals. It would be a brute-force type attack. In this
case, we're seeing more and more that applications and infrastructure
are being attacked, not brute force, but more subtly.

The fact that somebody that is trying to effect an advanced persistent threat (APT)
against a company, means they're not looking to set off any alarms
within the organization. They're trying to stay below the radar and stay
focused on doing a little bit at a time and breaking it up over a long
period of time, so that people don’t necessarily see what’s going on.

Gardner: Raf, how does that jibe with what you are seeing? Is there a new type of awareness that is, as George points out, subtle?

Los: Subtlety is the thing. Nobody wants to be a bull-in-a-china-shop hacker.
The reward may be high, but the risk of getting caught and getting
busted is also high. The notion that somebody is going to break in and
deface your website is childish at best today. As somebody once put it
to me, the good hackers are the ones you catch months later; the great
ones, you'll never see.

That’s what we're worried
about, right. Whatever buzzwords we throw around and use, the reality is
that attacks are evolving, attackers are evolving, and they are
evolving faster than we are and than we have defenses for.

They are evolving faster than we are and than we have defenses for.

As
I've said before, it’s like being out in a dark field chasing
fireflies. We tend to be chasing the shiny, blinky thing of the day,
rather than doing pragmatic security that is relevant to the company or
the organization that you're supporting.

Gardner:
One of the things I've seen is that there is a different organization,
even a different culture, in managing network security, as opposed to,
say, application security, and that often, they're not collaborating as
closely as they might. And that offers some cracks between their
different defenses.

George, it strikes me that in the telecommunications arena, the service providers
are at an advantage, where they've got a strong network history and
understanding and they're beginning to extend more applications and
services onto that network. Is there something to be said that you're
ahead of the curve on this bridging of the cultural divide between
network and application?

Turrentine: It used to
be that we focused a whole lot on the attack and the perimeter and
trying to make sure that nobody got through the crunchy exterior. The
problem is that, in the modern network scenario, when you're hosting
applications, etc., you've already opened the door for the event to take
place, because you've had to open up pathways for users to get into
your network, to get to your servers, and to be able to do business with
you. So you've opened up these holes.

Primary barrier

Unfortunately,
a hole that's opened is an avenue of an attack. So the application now
has become the primary barrier for protecting data. A lot of folks
haven't necessarily made that transition yet to understanding that
application security actually is your front row of attack and defense
within an organization.

It means that you have to now
move into an area where applications not only can defend themselves, but
are also free from vulnerabilities or coding flaws that can easily
allow somebody to grab data that they shouldn't have access to.

Gardner:
Raf, it sounds as if, for some period of time, the applications folks
may have had a little bit of an easy go at it, because the applications
were inside a firewall.
The network was going to be protected, therefore I didn't have to think
about it. Now, as George is pointing out, the applications are exposed.
I guess we need to change the way we think about application
development and lifecycle.

Los: Dana, having
spent some time in extremely large enterprise, starting in like 2001,
for a number of years, I can't tell you the amount of times
applications’ owners would come back and say, "I don't feel I need to
fix this. This isn’t really a big risk, because the application is
inside the firewall.”

Even going back that far, though, that was still a
cop-out, because at that time, the perimeter was continuing to erode.
Today, it's just all about gone. That’s the reality.

So
this erosion of perimeter, combined with the fact that nothing is
really internal anymore, makes this all difficult. As George already
said, applications need not just to be free of bugs, but actually be
built to defend themselves in cases where we put them out into an
uncertain environment. And we'll call the Internet uncertain on a good
day and extremely hostile on every other day.

Turrentine:
Not only that, but now developers are developing applications to make
them feature rich, because consumers want feature-rich applications. The
problem is that those same developers aren't educated and trained in
how to produce secure code.

Los: I think
nothing illustrates that point better than looking at the way we built
legacy applications in extremely large enterprises that were introduced
by a fantastic technology in 1976-1977 called the Rack app. It was
really well built for the applications of the time, maintaining data
access and authentication at a reasonable level.

Then,
some of the applications continued to be built and built and built and
built over time. We decided, at some point that we make them accessible
“outside the firewall.” We slapped the web interface on them and blew
all those controls out. So something that was once a solid technology is
now a dumb database where anybody can access it, once they get back
some spaghetti code in HTML.

Turrentine:
The other thing is that too many organizations have a tendency to look
at that big event with a possibility of it taking place. Yet hackers
aren’t looking for the big event. They're actually looking for the small
backdoor that they can quietly come in and then leverage that access.
They leverage the trust between applications and servers within the
infrastructure to promote themselves to other boxes and other locations
and get to the data.

Little applications

We
used to take for granted that it was protected by the perimeter. But
now it isn’t, because you have these little applications that most
security departments ignore. They don’t test them. They don’t
necessarily go through and make sure that they're secure or that they're
even tested with either dynamic or static analysis, and you are putting
them out there because they are “low risk.”

Los:
The lesson learned is that organizations that have 500, 600, 1,000,
1,200, or 2,000 applications in the corporate space have to make a
decision on what’s going to be important, what they are going to
address, what they are going to let fall behind. There are a certain
number of apps you can review, a certain number of assessments you can
do, and everything else just has to fall away.

What
you've just highlighted is the extreme need to understand, not just the
application as a singular entity, but interconnectedness, data
interchange, and how data actually flows.

Just because you are developing a marketing app over here, that app may be no big deal in a vacuum, but because of server consolidation, virtual machines (VMs), or the cloud-computing environment you are deploying it to, it now shares space with your financial system.

You
have to know that, when you're doing analysis of these things. And this
actually makes it a necessity that security people have to have these
types of analysis skills and look just past that one autonomous unit.

The fact is that many developers are going to take the low path and the
easiest way to get to what is required and not necessarily understand
how to get it more secure.

Turrentine: It
may actually be more diverse than that due to the fact that there may
be an intermediary system that both the non-secure app and the “risky”
app talk to, and just by the fact that they are interconnected, even
though it's not a direct interconnection, they are still exposed.

Gardner:
Let’s chunk this out a little bit. On one side, we have applications
that have been written over any number of years, or even decades, and we
need to consider the risks of exposing them, knowing that they're going
to get exposed. So is that a developer’s job? How do we make those
older apps either sunsetted or low risk in terms of being exposed?

And
on the other side, we've got new applications that we need to develop
in a different way, with security instantiated into the requirements
right from the get-go. How do you guys parse either side of that
equation? What should people be considering as they approach these
issues?

Turrentine: I'm going to go back to the
fact that even though you may put security requirements in at the
beginning, in the requirements phase of the SDLC,
the fact is that many developers are going to take the low path and the
easiest way to get to what is required and not necessarily understand
how to get it more secure.

This is where the education
system right now has let us down. I started off programming 30 years
ago. Back then, there was a very finite area of memory that you could
write an application into. You had to write overlays. You had to make
sure that you moved data in and out of memory and took care of
everything, so that the application could actually run in the space
provided. Nowadays, we have bloat. We have RAM bloat. We have systems with 16 to 64 gigabytes of RAM.

Los: Just to run the operating system.

We've gotten careless

Turrentine:
Just to run the operating system. And we've gotten careless. We've
gotten to where we really don’t care. We don’t have to move things in
and out of memory, so we leave it in memory. We do all these other
different things, and we put all these features and functionality in
there.

The schools, when they used to teach you how to
write in very small areas, taught how to optimize the code, how to fix
the code, and in many ways, efficiency and optimization gave you
security.

Nowadays, we have bloatware. Our developers
are going to college, they are being trained, and all they're learning
is how to add features and functionality. The grand total of training
they get in security is usually a one hour lecture.

You've got people like Joe Jarzombek at the Department of Homeland Security (DHS), with a Software Assurance Forum
that he has put together. They're trying to get security back into the
colleges, so that we can teach developers that are coming up how to
develop secure code. If we can actually train them properly and look at
the mindset, methodologies, and the architecture to produce secure code,
then we would get secure applications and we would have secure data.

Gardner:
That’s certainly a good message for the education of newer developers.
How about building more of the security architect role into the scrum,
into the team that’s in development? Is that another cultural shift that
seems to make sense?

It's just a reactive move to the poor quality that’s been put out over the last couple of years of software.

Los:
We can probably see some of that in the culture that’s developing
around the DevOps movement. To some extent, it's just a reactive move to
the poor quality that’s been put out over the last couple of years of
software, the reactive move by the smart people in the software
development industry to build tribes of knowledge and of intelligence.

It
goes all the way up and down the development and software lifecycle
chain, from the person who makes requirements happen formally, to the
people who write the source code, to those who package it, test it,
deploy it, monitor it, and secure it.

It’s a small
agile group of folks who all have a stake in, not just a piece of the
software development lifecycle, but that software package in general.
Whether they own 1 or 10 pieces of software or applications, it’s almost
immaterial. That ownership level is the important part, and that’s
where you're going to see maybe some of the changes.

Turrentine:
Part of it also is the fact that application security architects, who I
view differently than a more global security architect, tend to have a
myopic view. They're limited, in many cases, by their education and
their knowledge, which we all are.

Face it. We all
have those same things. Part of the training that needs to be provided
to folks is to think outside the box. If all you're doing is defining
the requirements for an application based upon the current knowledge of
security of the day, and not trying to think outside the box, then
you're already obsolescent, and that's imposed upon that application
when it’s actually put into production.

Project into the future

You
have to start thinking further of the evolution that’s going on in the
way of the attacks, see where it’s going, and then project two years or
three years in the future to be able to truly architect what needs to be
there for today’s application, before the release.

Gardner: What about legacy applications? We've seen a lot of modernization. We're able to move to newer platforms using virtualization,
cutting the total cost when it comes to the support and the platform.
Older applications, in many cases, are here to stay for quite a few
number of years longer. What do we need to think about, when security is
the issue of these apps getting more exposure?

Turrentine:
One of the things is that if you have a legacy app, one of the areas
that they always try to update, if they're going to update it at all, is
to write some sort of application programming interface (API)
for it. Then, you just opened the door, because once you have an API
interface, if the underlying legacy application hasn’t been securely
built, you've just invited everybody to come steal your data.

So
in many ways, legacy applications need to be evaluated and protected,
either by wrapper application or something else that actually will
protect the data and the application that has to run and provide access
to it, but not necessarily expose it.

I know over the years everybody has said that we need to be putting out more and more web application firewalls (WAFs).
I have always viewed a WAF as nothing more than a band aid, and yet a
lot of companies will put a WAF out there and think that after 30 days,
they've written the rules, they're done, and they're now secure.

A WAF, unless it is tested and updated on a daily basis, is worthless.

A WAF, unless it is tested and updated on a daily basis, is worthless.

Los:
That’s the trick. You just hit a sore spot for me, because I ran into
that in a previous life and it stunk really bad. We had a mainframe
app that had ported along the way that the enterprise could not live
without. They put a web interface on it to make it remotely accessible.
If that doesn’t make you want to run your head through a wall, I don’t
know what will.

On top of that, I complained loud enough and showed them that I could manipulate everything I wanted to. SQL injection
was a brand-new thing in 2004 or something, and it wasn’t. They were
like, fine, "WAF, let’s do WAF." I said, "Let me just make sure that
we're going to do this while we go fix the problem." No, no, we could
either fix the problem or put the WAF in. Remember that’s what the payment card industry (PCI) said back then.

Turrentine: Yeah.

Los:
You could either fix the problem or put mitigating control WAFs into
the slipstream and then we were done, and let’s move on. But it’s like
any security control. If you put it in and just leave it there, tune it
once, and forget that it exists, that’s the data that starts to fail on
you.

Gardner: I think there is even more impetus
now for these web interfaces, as companies try to find a shortcut to go
to mobile devices, recognizing that they're having a hard time deciding
on a native interface or which mobile device platform to pursue. So
they're just "webifying" the apps and data so that they can get out to
that device, which, of course, raises even more data and applications in
this field for concern.

Los: I liked that word, "webifying."

Tactics and strategy

Gardner:
So let's get back to this issue of tactics and strategy. Should there
be someone who is looking at both of these sides of the equation, the
web apps, the legacy, vulnerabilities that are coming increasingly to
the floor, as well as looking at that new development? How do we
approach this problem?

Turrentine: One of the
ways that you approach it is that security should not be an organization
unto itself. Security has to have some prophets and some evangelists --
we are getting into religion here -- who go out throughout the
organization, train people, get them to think about how security should
be, and then provide information back and forth and an interchange
between them.

That’s one of the things that I've set up
in a couple of different organizations, what I would call a security
focal point. They weren’t people in my group. They were people within
the organizations that I was to provide services to, or evaluations of.

They
would be the ones that I would train and work with to make sure that
they were the eyes and ears within the organizations, and I'd then
provide them information on how to resolve issues and empower them to be
the primary person that would interface with the development teams,
application teams, whatever.

If they ran into a
problem, they had the opportunity to come back, ask questions, and get
educated in a different area. That sort of militia is what we need
within organizations.

I've not seen a single security organization that could actually get the headcount they need.

I've
not seen a single security organization that could actually get the
headcount they need. Yet this way, you're not paying for headcount,
which is getting people dotted lined to you, or that is working with you
and relying on you. You end up having people who will be able to take
the message where you can’t necessarily take it on your own.

Gardner:
Raf, in other podcasts that we've done recently we talked about
culture, and now we're talking organization. How do we adjust our
organization inside of companies, so that security becomes a horizontal
factor, rather than group oversight? I think that’s what George was
getting at. Is that it becomes inculcated in the organization.

Los: Yeah. I had a brilliant CISO
I worked under a number of years back, a gentleman by a name of Dan
Conroy. Some of you guys know him. His strategy was to split the
security organization essentially uneven, not even close to down the
middle, but unevenly into a strategy, governance, and operations.

Strategy
and governance became the team that decided what was right, and we were
the architects. We were the folks who decided what was the right thing
to do, roughly, conceptually how to do it, and who should do it. Then,
we made sure that we did regular audits and performed governance
activities around it's being done.

Then, the
operational part of security was moved back into the technology unit. So
the network team had a security component to it, the desktop team had a
security component to it, and the server team had security components,
but they were all dotted line employees back to the CISO.

Up to date

They
didn’t have direct lines of reporting, but they came to our meetings
and reported on things that were going on. They reported on issues that
were haunting them. They asked for advice. And we made sure that we were
up to date on what they were doing. They brought us information, it was
bidirectional, and it worked great.

If you're going
to try to build a security organization that scales to today’s pace of
business, that's the only way to do it, because for everything else,
you're going to have to ask for $10 million in budget and 2,000 new
headcounts, and none of those is going to be possible.

Turrentine: I agree.

Gardner:
How would we describe that organization? Is there a geometric shape?
You hear about T or waterfall or distributed, but how do we describe the
type of organization you just described for our security?

Los:
An amoeba, or to be more serious, more like a starfish really. If
you're looking at the way these organizations are, you have the central
group and then tentacles that go out to all the other components of it. I
don’t have a flashy name for it, but maybe security starfish.

Any time you move data outside the organization that owns it, you're running into problems.

Gardner: George, how would you describe it?

Turrentine: I don’t know that it would be a single organism.

Gardner: More of a pond water approach, right?

Turrentine: Yeah.

Gardner:
Moving to looking at the future, we talked about some of the chunks
with legacy and with new applications. What about some of the
requirements for mobile in cloud?

As organizations are
being asked to go with hybrid services delivery, even more opportunity
for exposure, more exposure both to cloud, but also to a mobile edge,
what can we be advising people to consider, both organizationally as
well as tactically for these sorts of threats or these sorts of
challenges?

Turrentine: Any time you move data outside the organization that owns it, you're running into problems, whether it’s bring your own device (BYOD), or whether it’s cloud, that is a public offering. Private cloud is internal. It's just another way of munging virtualization and calling it something new.

But
when you start handling data outside your organization, you need to be
able to care for it in a proper way. With mobile, a lot of the current
interface IDEs and SDKs,
etc., try to handle everything as one size fits all. We need to be
sending a message back to the owners of those SDKs that you need to be
able to provide secure and protected areas within the device for
specific data, so that it can either be encrypted or it can be processed
in a different way, hashed, whatever it is.

Then, you
also need to be able to properly and cleanly delete it or remove it
should something try and attack it or remove it without going through
the normal channel called the application.

Secure evolution

I
don’t think anybody has a handle on that one yet, but I think that, as
we can start working with the organizations and with the owners of the
IDEs, we can get to the point where we can have a more secure evolution
of mobile OS and be able to protect the data.

Gardner:
Raf, any thoughts before we close out on some of these pending
opportunities or challenges when it comes to moving to the mobile edge
and to the cloud and hybrid services?

Los: To
echo some of the things our executives have been saying, without
sounding too much echo, I agree that every decade or so, we hit a
directional point. We make either a hard right or a hard left, or we
take a turn as an industry, maybe even as a society.

That
does sort of coincide with the fact that technology takes roughly 10
years to understand the full impact of it, once it has been implemented
and released, as I read somewhere a while back.

We're
at one of those points, as we sit here right now, where many of the
people, the kids going through school today, don’t know what a cassette
tape is.

When I mention my Zip drive from back in my technology days, they look at me funny. Floppy disks
are something they have only heard about or seen in a photo. Everybody
texts now. So technology is evolving at a pace that has hit a fever
pitch, and society is quickly trying to catch up or pretend like it’s
going to catch up.

Meanwhile, enterprises are trying
to capitalize on those technology changes, and security has to transform
with it. We've got to get out of the dark ages of, "What do you do for
the company? "Oh, I do security." No, you don’t. You serve the business,
in whatever capacity they tell you to. If you can’t understand that,
then you're going to get stuck in those dark ages, and we just won’t go
forward. That’s my line of thinking.

We're at the
point where something has to happen. Being here, walking through the
show floor, and having conversations with people like George, John
South, and other people who are leading security organizations
throughout the big industry players, and some really small ones, I am
hopeful. I think we actually get it. It’s, "Can we scale it and teach
others to think this way fast enough to make an impact before it all
goes wrong again?"

Enterprises are trying to capitalize on those technology changes, and security has to transform with it.

Gardner:
All right. I am afraid we will have to leave it there. With that, I
would like to thank our co-host, Rafal Los, who is the Chief Security
Evangelist at HP Software. It’s always a pleasure, Raf, thanks so much.

Los: Thanks for having me.

Gardner:
And I'd also like to thank our supporter for this series, HP Software,
and remind our audience to carry on the dialogue with Raf through his personal blog, as well as through the Discover Performance Group on
LinkedIn.

I'd also like to extend a huge thank you to
our special guest, George Turrentine, the Senior Manager at a large
telecoms company. Thank you so much, George.

I'm
Dana Gardner, Principal Analyst at Interarbor Solutions, your co-host
and moderator for this ongoing discussion of IT innovation and how it’s
making an impact on people’s lives. Thanks again for listening, and come
back next time.

Transcript
of a BriefingsDirect podcast on how perimeter security is no longer adequate to
protect enterprise data that resides in applications, and how one services provider is taking a different approach. Copyright
Interarbor Solutions, LLC, 2005-2013. All rights reserved.