R: SLA Security

From: Carmelo Floridia (cfloridia@lex.unict.it)
Date: 01/31/02 

From: "Carmelo Floridia" <cfloridia@lex.unict.it>
To: "Martin, James E." <martin@more.net>, <JohnNicholson@aol.com>
Date: Thu, 31 Jan 2002 19:13:48 +0100

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:martin@more.net]
> Inviato: mercoledì 23 gennaio 2002 19.36
> A: JohnNicholson@aol.com
> Cc: security-basics@securityfocus.com
> 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: JohnNicholson@aol.com [mailto:JohnNicholson@aol.com]
> Sent: Tue 1/22/2002 9:30 AM
> To: Martin, James E.
> Cc: security-basics@securityfocus.com
> 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." <martin@more.net> 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: JohnNicholson@aol.com [mailto:JohnNicholson@aol.com]
> > Sent: Fri 1/18/2002 1:41 PM
> > To: carmelo.floridia@keyconsultants.it
> > Cc: SECURITY-BASICS@securityfocus.com
> > 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
>
>

Relevant Pages

  • Re: Proper "stealth" behavior
    ... > It may be a security feature. ... > valid network response to a request. ... I think many people are now figuring out that about the term "Stealth". ...
    (comp.security.firewalls)
  • Re: My supervisor says Microsoft Updates are not needed. Is that tru
    ... There are serious problems of usability and security with the network, but the response every time is "we have a hardware Internet filtering product, we don't need to worry or change or update". ...
    (microsoft.public.windowsupdate)
  • Re: ICMP (Ping)
    ... (by just seeing the response if it is "destination unreachable" or ... with the lack of security... ... The type of attacks that people launch are going to be from ... >A network is going to be attacked if it's a target... ...
    (Security-Basics)
  • Re: [fw-wiz] Where do firewall Admins Sit in An Company
    ... What really irks me is that I believe the so called "security mainstream" ... is pushing dotted line reporting Security Management, ... structures and response is horribly slow. ... >companies lack a clue about what really traverses their network. ...
    (Firewall-Wizards)
  • Re: Cyberterrorism [was: Re: NSA wiretap, Friday night]
    ... Otherwise the ISP is just ... My most recent contacts were in response to appeals here by "imhotep" ... got an abuse complaint for email coming from our network, ... system on a server that saw all traffic coming from the customer side ...
    (comp.os.linux.security)