This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
Content-Type: TEXT/PLAIN; charset=UTF-8
BY MICHAEL GOLDBERG
SEPTEMBER 1, 2006
TriWest Healthcare Alliance counts on John Pontrelli to work
effectively with his technology colleagues to provide health care to
2.8 million members of the U.S. military and their families in 21
states. As VP and CSO, Pontrelli's responsibilities cover both
physical security and information security, and he has found it
imperative to form a tight working relationship with his CIO, Rick
Green. Pontrelli, a corporate security expert at Microsoft and W.L.
Gore before joining TriWest three years ago, spoke to CIO sister
publication CSO's managing editor, Michael Goldberg, about the
partnership he has formed with his CIO.
Michael Goldberg: In the past, you've described TriWest as being an
information systems - dependent company. What does that mean?
John Pontrelli: TriWest is in 21 states, basically the left side of
the United States, including Hawaii and Alaska. We have over 120
locations, and they are all connected via WAN to our corporate data
center in Phoenix. Most of our sites are on military installations, so
we have to coordinate with the military when we come in to set up our
routing/switching equipment, as well as bringing in the phone lines.
We house two or three major applications that our people hit from all
the 21 states to retrieve data and to input data. We have a lot of
data traversing our 21 - state region at any given time; we also push
our VoIP over our wide area network. Our entire company is VoIP, and
our security systems also ride over our network, so our network stays
That's a good segue into the relationship you have with your CIO, Rick
Green. Could you describe the nature of that relationship and, in a
business like yours, what makes the relationship important?
Rick and I both started at TriWest approximately three years ago. He
came in to redefine the IT - not only the infrastructure but the
applications - and we had just been awarded a new bid from the
Department of Defense. He had a huge challenge in front of him.
I was hired a few months after he came on board. One of the
conversations we had was around security and IT. My proposal was that
information security should reside in my department, primarily to free
him up to focus on connectivity, availability and support in the
businesses but also because implementing all of the security
requirements that the DoD had levied upon us was somewhat
unmanageable. We agreed right there, from the very beginning, that
that's how we were going to set it up and run it.
The other agreement we had was (and I think this is a big selling
point) that I don't audit his environment, I assess it. When we are
assessing the security posture of our routers, switches, databases,
servers and desktops, whatever we find, we share [that information]
with IT, so it's a collaborative effort. We then address any issue,
whether it's a technical, procedural or a person issue. If something
has bubbled up to the point where it needs Rick's attention, I meet
with Rick. We meet once a month, regardless, to go over a list of
things we want to talk about, but both of our doors are open to each
other if we ever want to talk about technology or security. We pop in
on each other all the time.
There's a lot of discussion nowadays about auditing systems and
procedures. You're emphasizing assessment as a means of collaborative
communication. What's the difference?
I'm a big fan of the word assessment; I don't like the word audit. It
carries negative connotations; it separates; it creates an adversarial
- type atmosphere even if there's a collaborative effort going on. We
never use the word audit within security and, in reality, we're not
auditing. We have vulnerability analysis tools that allow us to scan
our entire environment, from the inside as well as the outside. We do
this against a set of security policies that we have received from the
government for a certain security posture that we need to maintain in
order to hold onto our security accreditation. When we're doing these
scans, IT is aware of it. They're always waiting for the results
because they want to know - just as much as security wants to know if
the environment, application or network is not meeting requirements -
because they want to get it where it needs to be. We're assessing,
we're collaborating, and together we maintain a very high security
posture at TriWest that I think both Rick I are very proud of.
Is there a loop to close after the assessment to see that changes,
fixes or improvements are carried forward? Is that handled by your
group or the CIO's?
It depends upon whether it's a technical, procedural or people issue.
Our scanning goes on continually (we have a set scanning schedule) so
if the issue is still there when we go back and scan again we notify
IT. Most times, IT tells us if they're going to be able to fix it and
in what period of time. There's always reasons why things aren't where
they need to be, but the good part is we all communicate very well and
we're all on the same page.
From my perspective, a security perspective, and probably from Rick's
perspective as well, the last thing we want to do is be surprised.
It's the unknown that really keeps me awake at night.
How did you and your CIO identify the boundaries between security and
The boundary conversation was part of the initial conversation Rick
and I had where we agreed that it made sense for me to have
information security. Some of the typical security toolsets that IT
was either looking at or was using moved over to the corporate
security team. Some of the more traditional security items, which can
also be called IT items, we had more in - depth conversations on, such
as firewall management.
For example, sometimes the firewall is viewed as a security tool and
other times it's viewed as a networking or routing tool. My initial
thought was perhaps security should oversee the firewall so we could
validate the firewall rule set, do our assessing and make sure all the
configurations were correct. The response to that was like, "Well
John, what happens if someone calls you at midnight because they can't
get into the network and they need you to open up a port? Are you
going to take care that?" And I said, "No, we don't have that
infrastructure. We're not ready to be a 24/7 customer support for
connectivity and availability." So it made sense for an item like that
to stay within IT because IT is accessible 24 hours a day to help our
business customers. What we do on the backside is collaborate to make
sure that the security configuration, process and policy for the
company is in place and being followed.
That communication must carry over into new kinds of operations that
you have to implement.
It does. We recently implemented wireless. We'd been running wireless
in a test environment for over a year, and we wanted to put it into
production. We worked with the DoD to validate our security posture
and configuration for our wireless. We had multiple meetings between
security and IT, and we brought in an outside party to make sure we
weren't missing anything and that the configurations were where they
needed to be. Part of that process was who's going to write the policy
for wireless, what kind of forms are we going to have end users fill
out, who is going to oversee the configuration and who is going to
monitor the intruder detection for wireless? All of those pieces
needed to be discussed up front and agreed to, which we did. We
implemented it, and we're happy to say that we feel very good about
our wireless implementation.
You make the point that the relationship you have with your CIO leads
to both higher expectations and higher performance.
Yes. If Rick is focused on connectivity, availability and making sure
that our business units are up and running, and that's his core focus,
then there's a pretty high expectation set there. Conversely, the same
holds true on the security side around confidentiality, integrity and
all of the things we're doing around compliance and validating that
our systems, applications and everything are configured and hardened
to the level they need to be. Now it's very clear to the senior
leadership in the company who's in charge of which area, and if
there's an issue in one of those areas they know where to go. It
creates a sense of accountability, a sense of clarity and, I think, a
set of higher expectations.
What do you think is the most important thing for CIOs or CSOs to
think about in terms of their relationship with their counterpart in
security or in IT?
I think the sooner organizations can create that collaborative working
relationship between the CIO and the CSO, the sooner the organization
will benefit. Start that relationship and set some of the areas of
responsibility and begin meeting on a regular basis. I learn so much
from Rick every time I meet with him. At the same time, he knows I'm
going to bring to him anything that I see securitywise. We collaborate
well. It makes going to work every day very easy.
CSO Managing Editor Michael Goldberg can be reached at mgoldberg (at) cxo.com.
=C2=A9 2006 CXO Media Inc.
Content-Type: text/plain; charset="us-ascii"
HITBSecConf2006 - Malaysia
The largest network security event in Asia
32 internationally renowned speakers
7 tracks of hands-on technical training sessions.
Register now: http://conference.hitb.org/hitbsecconf2006kl/