Is this a trick question? Of course I have a good answer.
Answer: none.
You test with legitimate customers, and they will let you know if something
isn't working for them. These generally come in three types:
First, the ones with whom you have some kind of established direct
connection (frame, T1, whatever), these are typically business partners. If
these have a problem, either they'll let you know or your network management
system will (you do have a network management system, right?).
Second, the ones with whom you have an established virtual connection, such
as VPN or whatever. These are either permanent (remote offices or business
partners) or known clients (since they have a VPN connection with you), and
work the same way as the first ones, just using different technologies. If
there is a problem, you'll hear about it. It's a repair ticket, not a lost
customer problem, unless you do a crappy job of handling the matter.
Third, ones with whom you do not have a current established partnership,
such as web buyers. I do expect you'll be testing to see that they can buy,
that your system works, and will be monitoring purchasing rates and all
that. Test, verify, repeat as necessary. If that works, the only ones you'll
lose are the ones who have very little patience with your web site, and
you'll lose them anyway, especially if it really does suck.
Remember that we are talking about unacceptable traffic, which is not
legitimate. If you know that the traffic is legitimate, you won't be
blocking it. If the suspect traffic comes from a legitimate customer and is
blocked, your phone will start ringing (there's your network management
system alerting you, eh?). You then validate the client and their suspect
traffic, make a decision about letting it in, and if you decide to do so
then you make the change. Suddenly, legitimate traffic is not blocked. Then
you add the great work you did with this client to your monthly report to
exec mgmt. So, you won't lose any legitimate customers because you give exec
management a percentage instead of a total - you'll just avoid
statistics-induced heart attacks.
Chuck
_____
From: Mark Curphey [mailto:mark@curphey.com]
Sent: Wednesday, April 05, 2006 5:49 AM
To: chuck@netserco.com; 'Crayola'; security-management@securityfocus.com
Subject: RE: Reports for Exec Management
"And in the 7.8% of the traffic how many of our legitimate customers could
have been prevented from doing business with us?"
You know that question will be asked and you know you don't have a good
answer........
And if you don't know of a story that all execs will relate to and probably
call you on heres a true one..... I worked for a big financial services
company in the Bay Area whose CIO was British (like me). Sussex Country
Cricket Club was usually blocked by most web filters ;-)
_____
From: chuck@netserco.com [mailto:chuck@netserco.com]
Sent: Tuesday, April 04, 2006 1:21 PM
To: Crayola; security-management@securityfocus.com
Subject: Re: Reports for Exec Management
Show the IDS attacks number as a ratio of the normal traffic volume:
15% of the traffic was blocked as unacceptable for whatever reason, such as
viral or hacker attacks, etc.
or, 7.8% of the traffic was blocked, etc.
Chuck
----- Original Message -----
From: Crayola
To: security-management@securityfocus.com
Subject: Reports for Exec Management
Date: Mon, 03 Apr 2006 23:35:58 -0400
I need to begin putting together monthly reports for
executive management (CEO) that show the value that the Information
Security department is providing to the company. The execs know what we
do, my senior mgmt feels we need to broadcast the value Infosec provides.
I know a couple things about exec reports.. keep them short (one page),
never propose a need without an answer, and huge IDS numbers will scare
them needlessly. How can I show value without being alarmist? If I say that
we
successfully blocked over 1.5 million attacks last month they'll have a
heart attack.
What do ya'll provide to your execs? Its tough to show the value of what you
do when that value consists of potentially making something not happen
(security incident).
Thanks,
Mike
