Maybe this one good parameters for a Security SLA?
Firewalls
Availability 24 x 7
Upgrade Software from vendor release 48 hour
Log Monitoring daily
Attack Reporting weekly
Auto-Response to know attak Yes
Virus scanning
Upgrading virus list daily
Upgrading for new virus 36 h (vendor release)
Intrusion detection
Upgrading Database of signature 24 hours (from vendor release)
Response to know attack immediatly (for know
signature)
New attck 48 hours
Availability not specified (too difficult
to specify the time)
Monitoring 24 x 7 (automatic)
Auto-Response No
> -----Messaggio originale-----
> Da: Martin, James E. [mailto:[EMAIL PROTECTED]]
> Inviato: mercoledì 23 gennaio 2002 19.36
> A: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Oggetto: RE: SLA Security
>
>
> What I'm referring to is a SLA to set expectations for event
> response from downstream networks. Bear in mind I'm exploring
> this from the perspective of a backbone provider to an
> educational network. What are other providers doing?
>
> Our base current response metric for customers is 30 minutes for
> critical events, on a 24x7 basis. We've consistantly met that for
> four years with a very small staff (remind me to address burnout
> issues another time).
>
> What I'm after is management of customer expectations to that
> response, as well as management of our own expecations to their
> responses. So, as a hypothetical SLA clause, if the customer has
> established a CSIRT, supports RFC abuse addresses, has an event
> response policy and capability as audited by us, has the staff
> and tools dedicated to providing their own event response
> capability, exchanged PGP keys with us, and maintains a high
> response level (reasonably similar to our own), we agree to trust
> them more from a backbone provider's point of view. While our AUP
> empowers us to protect the network, it's occasionally awkward to
> do that from a border router (especially involving NAT'ed
> networks, firewalls, proxies and so on). We could provide more
> time without taking defensive measures ourselves, with the
> expectation the downstream network has the capability to
> investigate and resolved problems.
>
> At the other end of the scale, there are downstream networks
> without trained technical staff, let alone even a part time event
> response capability. They lock up the doors at 4:30 PM and go
> home, and stay there all weekend (and all through summer
> vacations, etc.). Often, at these networks, decision making is
> done by completely non-technical administrators who have no
> ability to implement requested defensive measures, let alone
> access or read logs. Some of these do not have their own admin
> passwords, having completely "contracted out" system
> administration to community volunteers. Some of these networks
> practice security by obscurity, unintentionally hiding
> accountability even from themselves. Some of these networks think
> their Wingates are firewalls.
>
> We're working on these from an educational point of view, but the
> policies to protect the network have been in place for four
> years. In the last quarter, our security team took more than 1700
> events. This is 101% of the entire preceeding year. We have low
> expectations of additional staff or resources. Our parent
> organization currently uses SLAs to define base levels of
> expectations, with higher response and improved service after
> hours for those who choose to participate. These other SLAs
> require the downstream site to invest in hardware, software and
> training. If a site does not have the capability to react to a
> request to investigate and protect the network, then that could
> be taken into account in requiring a *shorter* time for response
> from that network.
>
> Our current practice requires us to make a best effort to contact
> the customer before defending the network. This has ranged from
> calling the campus police to locate a faculty member during a
> holiday break, to sending voicemail, e-mail and faxes to each of
> four responsible persons in a building we had good reason to
> belive would be locked and empty for the next week before
> defending the network.
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Tue 1/22/2002 9:30 AM
> To: Martin, James E.
> Cc: [EMAIL PROTECTED]
> Subject: RE: SLA Security
>
>
>
> Not to bandy words, but it sounds like you're more
> interested in a policy and procedures document rather than SLAs.
> The policy and procedures document would say here's "what" you
> have to do. The SLA says here's how we measure what you do.
>
> For example, in the case of a report of an outside attack,
> your contract with an ISP might say that the ISP will work with
> your technical people to promptly investigate the claim and will
> develop an appropriate response. The policy and procedures
> document could discuss types of attacks (DOS vs. crack, etc.) and
> the steps you and the ISP will take in the event of such attacks.
>
> The SLA might say that if you report an outside attack, the
> ISP will respond to you regarding the report within 1 hour 98% of
> the time and within 4 hours 99.5% of the time. You might even
> split the measurements depending on the type of attack. If you
> are experiencing a DOS attack, the response time might be
> different than if your are being cracked.
>
> Regarding downstream maintenance, patches, etc., a policy
> and procedures document would identify who is responsible for
> which activities, and specific requirements for keeping versions
> up to date (e.g., for security software you must be on the most
> current version (N), for other operational software you must at
> least be on N-2, for some non-critical software you must be on
> N-4, etc.), the process for implementing patches (e.g. install in
> DEV or TEST and run specified acceptance testing before moving to
> PROD). An SLA, on the other hand, would specify, for example,
> how quickly the vendor must install the latest version of
> something once it is released.
>
> Hope this is helpful.
>
> John
>
> In a message dated Tue, 22 Jan 2002 9:04:58 AM Eastern
> Standard Time, "Martin, James E." <[EMAIL PROTECTED]> writes:
>
> > I'd be interested in any SLA work done on security event
> response by an ISP covering the following areas:
> >
> > a. Defense of the network against reported outside attacks
> > b. Defense of the network against attacks reported from
> the site contracting for access
> > c. Downstream network/site obligations for maintenance,
> patches, upkeep in general
> >
> > I've tried a preliminary draft, based on both upstream
> and downstream obligations to respond to reported security
> events. The document sets out responsibilities and standard
> responses based on whether a site has any after-hours event
> response capability, and whether a site with the capability
> refuses action or declines to protect the network.
>
> >
> > What are others doing in this area?
> >
> > Thanks!
> > Jim
> >
> > -----Original Message-----
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> > Sent: Fri 1/18/2002 1:41 PM
> > To: [EMAIL PROTECTED]
> > Cc: [EMAIL PROTECTED]
> > Subject: Re: SLA Security
> >
> >
> >
> > A general SLA on security is kind of difficult.
> Generally, you want your SLAs to be specifically quantifiable and
> measurable, but it depends on the services that you are talking about.
>
> >
> > For example, if we were talking about anti-virus
> protection, you might have a service level for how fast the
> vendor implements the latest set of virus definitions.
>
> >
> > For security, you might have an SLA for time to
> implement a patch after the patch is made available by a relevant vendor.
>
> >
> > If your help desk SLA includes response time and
> problem correction time, then a response and resolution of a
> security breach or a virus could be subject to those SLAs.
>
> >
> > For an IDS, you could include a requirement to audit
> logs every certain period.
> >
> > John
>
>
