By now, most enterprises have established baselines for reporting on foundational IT controls. They've also leveraged control frameworks and resident technologies to assist in logging, auditing and reporting. The next milestone is to "raise the bar" on how this information and data are collected and managed by using fewer resources to achieve better results. This video examines what it takes to implement an effective security and compliance framework. Watch and discover:
- The top 5 questions to ask when shopping for a compliance solution
- Procedural guidelines to follow that will help advance your organization's compliance program to the next level
- How to raise the bar on your company's compliance success
- And much more.
This video was originally recorded in Feb. 2007.
Read the full text transcript from this video below. Please note the full transcript is for reference only and may include limited inaccuracies. To suggest a transcript correction, contact firstname.lastname@example.org.
Raising the bar on compliance success
Eric Parizo: Hello and welcome to Raising the Bar on Compliance Success,
with your guest speaker Richard Mackey. My name is Eric Parizo, and I'll be
your host today. By now, most enterprises have established a baseline for
reporting on foundational IT controls. There have also leveraged control
framework and resident technologies to assist in logging, auditing, and
The next milestone to raise the bar is how data is collected and managed.
The goal, using fewer resources to achieve better results. This will
provide a technical and procedural guideline for getting there, more
specifically it will touch on assessing applications, project management,
and workflow for auditing and foundation of duties, using threat
management and auditing tools for policy enforcement, data protection,
integrity and confidentiality, and finally tools for log file optimization,
auditing, and forensics.
Our speaker today, Richard Mackey, is one of the leading experts on
information security and compliance. As vice president of consulting firm
SystemExperts, he has advised leading Wall Street firms on overall security
architecture, virtual private network, enterprise-wide authentication, and
intrusion detection and analysis. He has been a frequent speaker at major
conferences including Information Security Decisions and has taught
numerous tutorials on developing secure, distributed application. Thanks
for joining us, Dick.
Richard E. Mackey, Jr: Thanks, Eric.
Eric Parizo: Now we're ready for your presentation, Dick. Take it away.
Richard E. Mackey, Jr: Thanks a lot Eric. Yeah, as Eric said, what we're
going to be talking about today is raising the bar on compliance success.
What this is all about, is we're assuming that you have a compliance process
in place, but you're trying to improve the effectiveness of it. As Eric said, I
am a vice president of SystemsExperts Corporation. I've been in the security
consulting business for about ten years. Prior to that I was at the Open
Software Foundation. So what you're going to hear today is based on
experience in the last ten years of helping organizations make themselves
more secure and then in the past few years focusing quite a bit on
compliance. I hope some of my direct experience is going to help you with
it. Let's take a look at our agenda.
The first thing I'm going to talk about, which is probably the most
important aspect of your compliance program, is having the correct
structure, having the right elements in it so that you can actually have an
ongoing process that allows you to comply year after year. So many
organizations start into their compliance, their life as trying to reach
compliance, and they all realize immediately that what they're going is
they're changing their organization forever and that they need a compliance
structure in place. I'll be talking about that.
Another, the next topic I'll be talking about, are some of the common
flaws. In my experience, looking at organizations, helping them try to meet
their compliance goals, many of them have the same flaws and we see this
over and over again. So maybe you'll see yourself in some of the results
that we've seen out in the world.
And then there are two different types of improvements that you can make to
your compliance activity. First, process improvement, and these are usually
what I suggest to people that they tackle first. And that's changes to the
business process that actually allow you to comply. They may even be policy
and technical processes that you might want to change, like how you
administer a system. But the first place I always want to look is the
business process site, to make sure that you reduce the amount of places,
the number of places that you really need to comply or use technology to
help you comply.
And then, lastly, what kind of technology improvements you can make to make
yourself more efficient, and be able to meet your compliance goals far more
Before we get into the details of compliance, let's step back and look at
compliance, what the basics of compliance are because compliance
with any regulation, contract, or standard requires a process. When I say
regulation, I mean think of like HIPAA or Sarbanes-Oxley, Gramm-Leach-
Bliley, FFIEC; and when I talk about contract I mean a contract between
your organization and some outside, another organization. So typically,
you'll have service level agreements that you'll have to live up to, and
that means that you'll have to comply with a set of rules associated with
that service level.
Another type of contract that is similar is the Payment Card Industry
Standard, the Payment Card Industry Security Standard. Now that is a
contract between you and the credit card provider. And then you can have
standards, or especially standards I should say, ISO-1779, COBIT, ITO, they
all require a process. And in fact a similar process can meet your
compliance goal, and the keys to success in meeting any kind of compliance
goals is first, understanding your goals. It seems almost unreasonable, it
seems almost ridiculous to have to say this, but many organizations really
don't understand what their actual compliance objectives are, and they
don't have them clearly documented.
So, first, understanding what you're going to have to do to be compliant is
the first step. So, knowing what regulations apply to you, what laws apply
to you, and what standards you're trying to reach are important.
Second, you have to choose appropriate metrics. What does it mean for you
to comply with that rule, and that might be very different depending on
what kind of business you are in. So if you're in a bank, it might be very
different than if you're on an application service provider. If you're a
small organization, it would be different than a larger organization. You
really need to choose appropriate metrics that match what your requirements
Then the next one is follow a consistent approach, and there are two
dimensions that you need to follow a consistent approach in. One is from
assessment to assessment where you're measuring your client you need to be
consistent so that you're not arriving at different conclusions as to the
level of compliance you achieve. You also need to look horizontally at your
organization to make sure that each organization who is participating in
your compliance activity, your program, is following a consistent approach
of measurement and have the same goal, so that's critical.
And then the next point, there are a lot of organizations that have a
misstep on, is establishing realistic expectations for progress. Almost
every organization that we see, when they first embark on their compliance
program, think that they're going to achieve compliance or whatever their
goal is in a very short time. And it's better to make sure that the entire
organization has realistic expectations for the type of process changes,
technical changes, that need to be made in order for you to comply and you
look at this as a multi-year effort in most cases.
So establishing realistic expectations can be a real help to you in trying
to structure your compliance activity by making sure that you can report,
"Well, we're at this point and these attributes, and then we'll be at this
point in six months from now with ultimate compliance in about two and a
half years from now." So you shouldn't be afraid to actually face the truth
that it does take time to comply and that there are different priorities,
different areas that you'll have to decide which place to comply first.
Then the critical elements of making sure that you succeed are making sure
that you have everything written down, documentation of a requirement and
your status, so you can look back, you can look at any given time, anyone
who's participating in the activity, can know what they're shooting for
what their status is, and who's responsible. So that's all part of
communication. You have to have a centralized location that will allow
people to check to see where they are, who's responsible, and what they
need to do.
And you also need participation from both the technical side and the
business side. What we're expecting is that your organization already has
established a process, a compliance process, because you're trying to
comply with something, one of those three areas that I talked before. Your
goal is to improve your effectiveness in compliance. So you want to apply
resources where you most need them yet you want to adapt to changes in a
regulatory environment and make yourself more adaptable. Track the
requirement closely and adapt as necessary. You need to put that kind of
flexibility in your process.
You need to understand and track your state, have some way everyone in your
organization can participate in the activity and know exactly what your
state is at any given time. You want to apply technology where it will make
you more efficient and provide you the most benefit in reaching your
compliance goals. You want to improve your efficiency and you want to
improve the accountability and tracking, meaning that you want to make sure
you know who is responsible for reaching a compliance goal and make sure
that they are held to those responsibilities, because it's one of the
problems that often happens in compliance is it often falls to a second or
And then what happens is people lose track of what they're responsible for
and then it only comes up again during the next assessment, you find out
that no progress has been made at all. So accountability is very important
and tracking, make sure that that's visible and there's some transparency
to the system is really important as well. So, how do you all these things?
Well I'll be talking about that next.
So the first thing you have to do before you embark on fixing any one piece
of your process is to understand, is to ensure that you have the basics
covered and I said that all of the compliance activity have the same basic
structure, so the common elements are: first, you have to have a risk
assessment and this is true in any compliance activity, and that means that
you are going to use a formal risk assessment process. I'll talk more about
Then, you have to establish your control, and your controls can be any
combination of three different things: a policy, a process, and a technical
control. So technical control I always list last, because even though it
may be very effective like stronger authentication or good access control.
Often you can void having to deploy technical controls if your policies and
processes are effective. If you can actually eliminate the problem before
it needs a technical control.
The next is measurement of effectiveness, so you've got a risk assessment,
you've installed some controls, and then you measure whether they are in
fact doing what they need to do to meet your compliance goal. They're
mitigating some risk.
The next step is adjustment and adaptation to improve these processes,
these controls that you've put in place, so you'll have a self-critical
analysis of what you've done, what controls you have in place, and make
sure that they're actually effective. And if they're weak, you'll adjust
and adapt, and you may actually adjust and adapt to changing regulation, in
fact. So while an interpretation of a particular regulation might be
accurate last year and your controls might be adequate, this year they may
be very different. And then what you do is repeat these steps over and over
and over again.
So what I suggest you do is you look at your compliance process and make
sure that you've got all those elements in there, that you have the risk
assessment, the control, establishment, measurement of effectiveness, and
adjustment and adaptation to ensure that the basic structure is covered.
If you look at security standards like ISO-27001, it suggests that you
follow what's called the PDCA process, a plan-do-check-act, and those
correspond to the steps I just mentioned. COSO is what's called a corporate
governance framework. COBIT is an IT governance framework. HIPAA and FFIEC
are regulations. All of these documents that describe the process that's
necessary to comply require a similar structure to the process that you're
going to use, so it's really important to make sure right from the start,
that you have all the elements that I mentioned.
If you step back and you think of security controls, why are they there?
They're there because you're trying to mitigate real risk and the only way
that you can identify and control is through a well-defined risk assessment
process, and you can't believe the number of organizations that do not have
them. As I say, in most organizations that we come upon, they have this
sort of seat of the pants risk assessment, and what ends up happening is
that sometimes very important areas are missed. Various controls are not
put in place.
And another area that we see a lack of risk assessment is that people put
much too much emphasis on some of the technical controls that they spend
wildly on some on faith multi-factor authentication, when in fact it's not
really dealing with the real risk. The passwords might have been fine, what
they needed was some sort of authorization control or better logging or
better monitoring, or a change in the business process to eliminate risk
altogether. So all the security standards that I mentioned, ISO-17799,
27001, all require that you have a risk assessment, and if you look at ISO-
17799, section 4 is all about risk assessment, basically, so take a look at
that if you can.
Most organizations don't have one, but there are places out there you can
look, and I'm giving you three different examples of places to look for
assessment methodology. The first is OCTAVE from Carnegie Mellon. That's a
formal risk assessment method that came out of a project at Carnegie
Next one is the General Accounting Office, this is relatively old document,
but it's still really useful, and having you structure who show be involved
in the steps that you need to take to actually understand what your real
risks are. And we're not just talking about technical risk here; we're
talking about business risk as well. Because it's only when the business is
at risk that you need to deploy technology to deal with them.
And then the next one is HIPAA, if you look for the MIF guidelines on
HIPAA, you'll find an entire document dedicated to risk assessment. So
there are many examples out there for people to use, so it's not lack of
examples where people are missing. It's just that, I think most
organizations don't really understand that they'll find anything new by
going through a more formal methodology in trying to analyze their risk.
So, the next item is understanding and tracking your requirement. The one
point that I want to make here, the major point I want to make is that
regulatory compliance is a continuous process, so if you look back at that
repeating process that I discussed, one of them is really understanding
whether your requirements are changing, because sometimes the regulatory
rules themselves change. So FFIEC may come out with a new rule or the
Payment Card Industry might come out with a new rule or HIPAA for that
Also, interpretations can change. A little while ago, the banking
community came out with a statement, FFIEC in fact, came out with a
statement that said all financial organizations, or banks that is, were
going to require the use of multi-factor or two factor authentication and
that they were saying what a problem passwords were and how insecure they
were. So it turns out the immediate conclusion that everyone jumped to was
that every bank was going to have to take on the burden and cost of dealing
with these token type devices, the smart cards, which was going to be a
So you can imagine that the banks were concerned and as a consumer I was
concerned because I thought it might happen that you ended up with the
cargo pants problem, I like to call it, where every organization that you
deal with is going to be handing you a different token. That means you're
going to have to walk around with hundreds of tokens and therefore you're
going to have pockets all over your pants.
But what happened was that one of the results of that rule change, what
happened was the interpretation of that rule allowed organizations to use
things like cookies that were persistent on your machine to act as a second
factor. So the interpretation was completely different even though the rule
went into effect, so what you need to do is watch those interpretations and
make sure that the decision you made last year is still going to be
compliant this year.
Also, another dimension that you need to look at is your business
environment and what effect and impact changes in it will have on your
ability to comply. So if you grow, your organization grows or shrinks it
may be more difficult or easy to comply. The structure of your
organization. If you were to merge with another organization, even though
both organizations were compliant, you have to look at what the impact of
that merger would be on the overall compliance of the new organization. And
then your business focus might change, you might offer new services, new
product, and what will that do to your ability to comply.
So looking at all those elements is very important to make sure that you
still understand what it's going to take to comply. Your threats may
change; you may be targeted by an organization. The technology you use
might make you more susceptible to certain types of attacks. If that's
true, you might need additional controls to make you more secure. So your
objective and your controls need to adapt to the changing environment, all
the elements of the changing environment that I just discussed.
The next thing that you do is you track requirements, so you have to
identify the sources for the compliance information that you're going to
use, those regulations you have, and any kind of guides that you're going
to use so you can make them available to everyone on the team who is
cooperating and contributing to the compliance effort. You capture your
objective, the metric, in some sort of common store that all the team
members have access to, like Wiki, centralized databases, SharePoint is a
We've seen this used, in particular actually, one large financial
organization used SharePoint as the common place where all the Sarbanes-
Oxley compliance activities are centered. This type of activity and this
kind of mechanism really works out well for an organization. And what you
want to do is revisit and have someone responsible for revisiting and
adjusting the objective, and making everyone on the team understand that
those have changed. Basically what this amounts to is you have to know what
your target is. Everyone on the team has to know when anything changes that
might affect their part of the client picture.
Now the next step, so you understand what your requirements are, the next
thing you need to do is conduct regular assessments. I was just talking
with a guy who works for a company, a credit company down in the South,
this morning and he was talking about doing his assessment bi-annually, I
think is every six months. Every six months or annually. So what you really
want to be able to do is set a rate of assessments that will keep your
organization on their toes and make sure that's what is derived, the
results are useful.
Some regulations are going to force you to do regular assessments because
you might be audited. Some won't, particularly if what you're trying to
comply with is a standard, like a security standard like ISO-17799 or
What's going to happen is you'll have that as your goal. You have to force
yourself to make these regular assessments happen, and make sure that
people view the compliance effort as just as important as it would be if
you were trying to comply with some outside agency. And what you want to do
is, you've captured your objectives and what constitutes compliance and
then you're going to assess yourself each period based on those objectives
and measures and you're going to record your state. What you want to do is
give yourself a report card.
What we do when we do assessments is we give a compliant, partially
compliant, or non-compliant grade, which ends up being for compliance it's
green, partial compliance is yellow, and red for non-compliance. So that
when you have this spread out, this report card actually gives you a good
overall sort of feeling for where you're in trouble and where you aren't.
The interesting thing is how useful it would be if you could somehow weight
the size of the report card and let people, of each of the boxes that told
you what your state was, based on the risk that each one of those items
represented to your organization.
So in the end, when you look at each one of these items, you want to claim
your work based on two factors: your risk and your effort, where the risk
to the organization is the primary motivator so you want to decrease the
risk, mitigate that risk as much as possible, particularly where it
represents a great risk for your organization.
And then another metric that you want to look at is effort. There are some
areas in compliance where it may be very easy to comply, so you might as
well knock those off, the low-hanging fruit off as quickly as you possibly
The key to succeeding at assessments is preparing, adequate preparation. So
you want to divide and conquer, and we've seen organizations do this well
and we've seen organizations fail miserably at this. What you want to do is
assign sections of whatever the compliance target is to various people
around the organization and make sure that that ownership is well-
understood and that they're held accountable for those areas.
And each one of those people is responsible for capturing evidence in a
consistent manner so you tell people that this is the kind of information
that I want compiled in regard to our practice in a particular area,
whether that's security policy, some were to make sure that your policies
were complete and accurate and up to date. Whether it's business continuity
or your human resources practices. All those areas should be documented
clearly and all the evidence that would be necessary during the assessment
should be compiled beforehand. You don't want to be going looking for this
and extend the assessment.
And then you want to share the information with the team. So, again, this
is another opportunity to use that common storehouse. And then you can also
use results of previous reviews. So you can look at audit findings and
reviews and find out where weaknesses are and then use that in the
assessment activity, and find out whether things have changed since those
audit findings were actually stated. So the whole point here is to
recognize shortcomings before some external assessor does or even an
internal auditor does, so you're totally honest about what your
organization is actually doing.
And then I recommend, and I mentioned this already, is consider alternate
remedies. There are three different types of remedies: change the business
process, and what one example is we deal with organizations all the time
who deal with application service providers, and these financial
organizations that we deal with quite a bit have to send sensitive
information - account data, Social Security numbers - out to their
application service provider. Well, they have sets of information inside
their organization and sometimes they don't look very closely at the kind
of information that they're sending out to their partners.
So what they need to do, though, is look closely to make sure that they're
not taking on an additional compliance burden by sending out sensitive
information unnecessarily. So you can imagine this in a healthcare
environment where, if you can avoid sending out the sensitive healthcare
information, you could avoid altogether the compliance problem of dealing
with that partner. If you could change the Social Security number to some
other unique identifier, you could avoid the exposure and the compliance
risk that that relationship now represents.
The next one is you want to define policies if possible, so changing
business processes, then define policies that may make the process more
transparent. So, for example, if you had in Sarbanes-Oxley, if you have
people who have to get access to the financial information what you want to
do is include by policy and enforce by mechanism if necessary, the
approvals of all the people who are responsible for that financial system.
It might be the data owner, it might be the process owner like the
accounting group, and it might be the technical owner so if you have all
those people involved before someone wants to add access to a critical
system, then that whole process becomes more transparent and fraud becomes
more difficult to perpetrate.
And then, finally, technical controls. What kind of technical controls can
actually make business processes and policies either more effective or are
necessary because there's no other mechanism to be able to protect
Now, the next item, is a tall order actually. Most organizations don't do
this very well, and that is accepting limitation. Compliance may not be
possible immediately. I mentioned that right at the beginning, but most
organizations think they're going to take a four month project with two
people put on it and they're somehow going to comply. And this is
particularly important on a broad security standard like ISO-17799. Getting
you to comply immediately, chances are you're wrong.
So ISO compliance is a very tall order. It has a hundred thirty-five
different sections that you need to comply with. Most of these are
subsections, but you have to look at each one of these practices to
determine, one, whether it's applicable to you and, two, what you need to
do to actually comply. And most organizations fall short in a variety of
areas right from the start. And most of them don't have very mature
controls in place, even if a control exists in a particular area. So you
need to determine after you do an assessment what your priorities are, and
that's again based on that risk assessment.
One other thing you need to have in place is you need, every time you have
a policy in place, there's a possibility that you're going to have
exceptions to the policy. And it's better to recognize and have a mechanism
that you can live with your exceptions rather than to ignore them. So you
need to capture your exception through any policy, and then develop the
business reasons why the exception is manageable and why you can deal with
it and also, over time, try to eliminate those exceptions.
But having the kind of descriptions for an auditor or an assessor to say
where there are in fact exceptions and where you're going to deal with
them, how you're going to deal with them why they're manageable is a very
strong statement and in fact shows a maturity of your entire security
program, compliance program.
So now I want to talk about standard-based assessments and why
organizations have found them useful. The reason why 27002, ISO-17799,
they're exactly the same standard, the only thing is in April 2007 ISO-
17799 name was going to change to 27002 officially, but there's no
substantive changes to the actual text of the standard.
What is it? ISO-17799 is a useful standard because it's a whole set of
security practices, basically a laundry list of security practices that
could be applicable to any organization. So it's written in general so that
any organization can look at it and find some application. Find some
objectives or goals and a set of practices that might allow them to make
those controls effective. So some of them are going to be applicable, some
of the mechanisms mentioned, some of the practices that are going to be
applicable and some not, because depending on your business environment,
for example, and your technical environment.
Now for some organizations, 27002, ISO-17799 may be an end unto itself,
meaning that that could be the only real goal is to have a structured
security program that they can claim they comply with, because what it does
is it's a statement that you're using a set of control objectives that are
specified by an international standard organization, unlike other
frameworks or mechanisms that you might use to compare yourself against. It
provides and objective framework.
If you were going to look at SAS 70s for example, SAS 70s are not as
objective a framework as ISO-17799, because SAS 70s, the control objectives
are actually chosen by the organization being audited. The policies that
they establish are the ones that are going to be audited, and the auditor,
the auditing firm itself. So those objectives can change from organization
to organization to organization, whereas the controls objectives with ISO-
27002, 17799 are the same objective for every organization. Their
interpretation may be different due to the difference in businesses and the
different size of the organization but at least you know you're headed for
the same goal. And that means that you can actually compare, at least to
some degree, the practices of one organization to another organization and
certainly from one assessment to the next assessment based on the
consistency of method used to effect. So that's why organizations have
found this standard useful.
Now, I mentioned earlier, that what you want to do is you want to make sure
that everyone knows exactly where you stand, and as a result of, say, ISO-
17799 issue, you want to capture your results in report cards. That's the
method that we use. The result assessment should be completely easily
understood by anyone involved, and it should be available to everyone on
the team to understand exactly where they stand.
In addition, what you want to have come out of any assessment is a set of
action items and responsibilities, so out of it we'll say you need to do
this to comply and then you assign that to someone and by the next
assessment they should have made progress on that or at least have a reason
why they haven't.
Another very important aspect of compliance in general is you have to have
multi-disciplined involvement, meaning that you have to get the business
involved. I talked about this earlier, but the assessment should reinforce
the responsibility of the business and technical participants to cooperate.
So you don't want your compliance activity to become an IT-only effort.
That is one of the worst things that can happen, because it actually, it
means, that you're really not going to be compliant because you don't have
control over the business processes and the business information that's
actually meant to be protected by the compliance activity.
So if you look at ISO-17799, for example, there are aspects of Human
Resources, hiring, there's business continuity where you have to identify
what the business involvement's going to be and how they continue operating
when the IT infrastructure needs to change, disasters occur. And then there
are areas of security policy and even security governance where it
requires, these standards require, that you have business involvement in
setting policy and reviewing policy in an ongoing basis. So you want to
encourage participation of the business groups in general.
And one of the ways to do that is to make sure that one of the options you
always attempt to use is a change in business process to become compliant.
So eliminate problems through business process changes before technology is
That basically handles, I said there were process changes, and there are
also technologies that you can use to achieve compliance and there are four
of them I want to talk about today. One is identity management, really
identity and access management, there's vulnerability management, log
aggregation, and then encryption.
The first one is identity management, or identity and access management,
and these products, the products that you can actually buy today form a
variety of different vendors, help in a number of ways. They consist of,
probably first and foremost, they request an approval workflow for IDs and
Let me step back for a second, tell you a little bit about what identity
management, identity and access management, does. It's basically
controlling how people are provisioned, what kind of account they get, and
all of the approvals that are necessary and the control of who has access
to what throughout an organization. So that's obviously a very important
part of every compliance activity.
So the first item is that they request an approval workflow for the
creation of IDs and changes to privileges. And that means that when a
person puts in a request for a certain account to be created, let's say a
person's coming on board, a request comes out of human resources that
Bob needs an account on system A, system B, and system C. Then the
system takes that and pushes the request to the various people who have
to approve it, and then only after the approval is done is the account actually
created. So it acts as a gate and an auditing mechanism to capture who's
involved in the creation of that account.
The same goes for changes in privileges. If a person has a job, they change
jobs, maybe privileges are done away with, disabled, a privilege is added,
it can be done through this system. The next is it helps re-certification
of access. If you're part of a financial organization, you realize that
every year at least your supervisors are being asked which people should
have access to which system. They're being given a list of systems and
applications they have access to and they're saying are these are all
right? Information owners and process owners might be given the same list.
These lists can facilitate that entire process by being integrated into it.
The next is reporting. Being able to report who has access to what, what
accounts exist, how long they've existed etc. is critical to a big part of
these projects or products I should say. You can also automate
administration through this. So after all the approvals have taken place,
you want to create an account in a Windows domain for example, this could
automatically do it for you. And then they can actually allow, check to
make sure that people aren't given privileges that they're not supposed to
be. So you can have policies in place that say if a person has the right to
create a request for some financial activity, they cannot be in the group
that does the approvals for the same activity. You can actually have access
control based on policy.
The biggest payoff in these systems tends to be the workflow because it
adds to that transparency that I talked about before. So that means that
having people involved in the process, having all of the approvals
captured, means that they are now responsible for the individual who have
access to these systems. So that means that there's a certain transparency
to the entire process, these systems provide that.
What we've seen is the investment, which could be very large pulling one of
these systems have a long-term payoff because it reduces the cost of a
mistake associated with these systems. It makes sure that people are
involved in the approval process, and it allows you to have a much more
automated certification process as time goes on.
The next item is vulnerability management. Vulnerability management systems
are basically one-stop shops, recognizing that there are part of any one of
your systems and applications, so most of them basically scan systems and
look for problems, by recognizing the version of the OS, they might have
agents installed various systems to monitor how they're configured and what
versions of various software is installed.
So what they do is they identify vulnerabilities, operating systems,
whether there are viruses there, they can be integrated with a virus
protection scheme and they look at configurations to make sure they match
the configurations that you have established the correct configuration for
any given system. And then they can give you a view of the status of any
one of your systems through dashboard so they can help you keep track of
the systems that need to comply with a particular rule.
And they can, in some cases, even apply fixes where they're necessary, so
recognize that the system is out of date and then push the patches off to
the system and installs them bringing them up and running, which always
makes me a little bit nervous, but the fact that these can actually do
The other thing they do is they give you an idea of what the most critical
systems are in the display by showing you them in a different color for
example and calling your attention to them. And they actually help you
quantify the risk associated with various systems by looking at a couple of
different attributes of them. One is the network topology, are they close
to the Internet. If something went wrong or they were vulnerable to a
particular type of attack, they may be more problematic, those systems
might be more vulnerable because they're closer to the Internet and more
susceptible to access.
So they can help you in that regard, and then they can give you, they can
scan configurations and tell you what configuration any one of your systems
is to a certain degree. So one of the points here is particularly if you
deploy these systems inside the environment, a critical environment that's
a target of your compliance activity, like the financial systems for
Sarbanes-Oxley or your healthcare information storage for HIPAA. They can
reduce the effort necessary to monitor those systems and they can give you
an idea of what your state is across an entire large corporate network.
That's a real plus.
The next one is log aggregation. Organizations offer enable logging. I
can't tell you the number of times that I've gone into an organization and
asked them whether they had their logging turned on their web servers or
their application servers and so on and they say yes, yes. Unfortunately,
the log often goes completely un-reviewed, because there's no way to deal
with the amount of data the number of different formats and the problem can
be, in a large organization, so distributed, that there's no way to get a
handle on what all these activities mean together.
So if you want to have a good handle on your monitoring, you have to
somehow be able to put all this log information together in some sensible
way. And these log aggregation products, they can help you, A), understand
log formats, they can integrate what would be completely incompatible log
formats that are emanating from the various products that you have. They
can integrate across network boundaries, so you can put agents in place
that allow forwarding logging information and then collect it in a
centralized location. They can integrate with some sort of alert that can
page you if certain problems occur.
And they can recognize particular types of events as being important so
that, again, you might be paged or they might accumulate and then finally
set off a page after a certain threshold. And they can be customized to
your environment. Now, this all takes a lot of work. These things don't do
all of this automatically, but they're the infrastructure that allows you
to deal with compliance by doing a better job monitoring your critical
Now another area that's very important is encryption, because many of the
regulations out there, like HIPAA or contracts like the Payment Card
Industry require confidentiality protection. So the encryption products can
encrypt files, they can encrypt streams, they can actually do field
encryption and archive encryption, and sometimes integrated with hardware
support to do this very, very quickly and transparently in your network so
that you don't have to change your product to be able to integrate these
Now, the features that you want to look for when you're looking for
encryption products is the first one is that transparency that I talked
about, transparent encryption where your products don't have to be changed
to take advantage of encrypted data.
Another area that you really need to have, which many organizations who
install crypto features inside their production software do a poor job of
key management. What you want to do is make sure that your source code,
your applications, never see a plain-text key, which means that you have to
have an extraction that allows that key to be hidden and stored, and
changed, etc. So it supports things like periodic key rotation, which is
not easy for an organization trying to implement their own crypto features
inside and organization. And when I say implement your own crypto features,
I mean encrypting data inside your product. I don't mean creating your own
crypto algorithms, which is a no-no for anyone except those that are known
Then you also need key escrow in many cases so if for example, the SEC says
that you need to maintain, make sure that all e-mail that might be used in
some sort of court case is discoverable, you have to make sure that those
keys are stored away so that you can't render the encrypted data back into
a plain-text form. You also need key history to be able to go back and
decrypt information that you might have encrypted in past keys. And you
might even need split knowledge for key controls or critical areas where
crypto is going to be necessary like in the SWIFT environment, the banking
environment. There is sometimes a requirement for two people to be
involved, each knowing half of the key so that it adds yet more
accountability in the process of establishing a relationship between two
banks for example. As always, you need support for both symmetric and
I'm going to indulge myself for a second, because I saw something recently
that I'd like to, I'd just like to give people a glimpse of where
compliance can be helped by integration with technology in general. Some
organizations, in fact one that I've seen recently, has devised a method
for integrating some of their compliance activities into their development
environment. What I mean by that is that as they create a new product, they
actually have the requirements created and tracked, which is a requirement
in ISO-17799, but it's actually in their development system that this
feature is available.
And then when there's a policy, like a change control policy, and a set of
procedures there are actually links inside the system to feed the procedure
to enforce the procedure, and a link back to the policy to see why that
procedure exists. So if someone wants to make changes to a particular piece
of software, there's a procedure they have to follow and there are
mechanisms to enforce that procedure and a pointer back to the policy to
understand why the policy, that procedure exists. And then there are change
control processes involved and mechanisms involved to be able to make sure
that this system stays and keeps its integrity. Unfortunately, all these
features are only available in one system that I've ever seen, but it is a
glimpse of what I think the future may hold.
Here we are at the end, I just wanted to say that there are opportunities,
clearly, for improving your compliance. And there are two different ways,
really: process changes and technology changes. The first thing you need to
do in looking at your process is make sure that you're dealing with that
structure of your process is a good one, and that it follows that plan-do-
check-act framework. Next is you want to use a risk assessment to improve
the focus and make sure that you're dealing with real risks and mitigating
the most important risks first. And then you want to improve the efficiency
with technology wherever that's possible. And bear in mind that there's
probably not technology that you can deploy without changing your processes
So take a two-pronged approach continuously hone your processes, look
closely and critically at your processes, focusing on the risk assessment
as the major driver, and then deploy technology wherever there's a clear
payoff. And remember, that they can be really useful, but don't be fooled
by the hype that the salespeople from the vendors will give you that they
are the silver bullet to compliance. There are not products out that
actually really make you comply. They only work in the context of your
process. Well, thank you very much.
Eric Parizo: All right, Dick, thank you for that great participation. Once
again, we'd like to thank Richard Mackey, Vice President at SystemExperts
for joining us today and for more information on compliance control
framework, read Dick's exclusive companion tips via the link on your screen
and be sure to check out the rest of our informative content at
searchsecurity.com compliance school also via the link on your screen.
Thanks to all of our listeners for joining us. I'm Eric Parizo. Stay safe