>At 10:32 AM -0400 4/20/98, Brock, Todd A wrote about frame relay: > >>I too would be REAL interested in any responses to this inquiry. Because I >>am VERY doubtful that there will be any but purely anecdotal response >>supporting the assumption of insecurity or known hacks or eavesdropping etc. >>on a Frame link. IMHO if you think Frame is insecure, then you might as >>well assume that ALL public telecommunication is. (This includes "private" >>leased lines). Rick Smith <rick_smithat_private> added: >I think this hits the nail squarely on the head. If the data owner believes >that attackers have the means and motive to intercept their traffic as it >traverses public telecom networks, then additional security is warranted. >If the data owner doesn't believe the attackers' benefits will outweigh >their costs, then encryption is unnecessary. This sketches out the classical equation. (I note, however, that Lyndon David <lyndondat_private> introduced this question with a comment that his client, BigCorp, was sending information of "very high value" over the Frame Relay links unencrypted.) The issue should turn on the value of the potential intercept or data corruption or DoS to some potential adversary. What Mr. David seemed to imply was that his client was disregarding his risks because he had an assurance from the Telco or some other frame relay provider that FR was a priori secure, even without crypto. As I recall, FR has better thruput than X.25 largely because it eliminates the error checking and correction done at the data-link level and moves the function to layer three to rely on more intelligence resident in the workstation. (I note, in passing, that the lack of _inherent_ security and integrity mechanisms has reportedly been one reason that frame relay has been rarely used by either the US or UK military agencies.) I presume the Telco's assurances largely reflect assumptions about the inherent physical security of the fiber optic links which are typically (always?) used for the FR transmissions. That, doubtless, does raise the barrier to attacks and intrusions, but it by no means eliminates the threat or vulnerability. So the question comes down, again, to the value of an attack to some potential adversary. Just to fill in three generic categories of threats, someone responsible for this data should consider: * Passive Intercept Attacks (monitoring of plaintext data flows, capturing ID numbers and passwords, traffic analysis) * Network-Based Attacks (insertion or modification of data in transit and penetration of corporate security perimeter through a privileged access link: corrupting logon and access controls, hijacking sessions, masquerading, and data manipulation) * Insider Attacks (compromise of data or access, and possible modification of system protection.) On the latter, I thought Chris Brenton <cbrentonat_private> offered a wonderful war story that might catch someone's attention. >>I've done this by accident myself and I think someone mentioned to me that >>there is an article over on Phrack. Just change the DLCI number of your >>connection to another number used by someone else on the same switch. >>You'll start receiving a copy of all their inbound frames. This sort of connection-oriented link is seldom designed with protections against insiders -- who might potentially pop up and play within any of the corporate end-points... or within the FR provider itself. Wouldn't a BigCorp risk analysis establish some potential value on the information on-line? (The trick then would be to get BigCorp to ask if the RF supplier is willing to bond the security of his service for some meaningful fraction of the potential loss.) As Rick suggests, until you, or BigCorp, or the FR supplier start dealing with real numbers for the potential loss -- and, as a lesser concern, potential adversaries who might benefit -- the framework for this discussion never drop out of the ether. Potential loss -- not the list of feasible techncial attacks -- defines the vulnerability you want them to consider. In some environments, ongoing authentication of the data is vastly more important than confidentiality (and the latter available for an international net only with some hassle.) Nevertheless, the cost of crypto for either confidentiality or authentication on an international RF net is also solid number you might get for your client's consideration. Might give some thought to strong user authentication options too;-) Suerte, _Vin >In certain industries you do have national level eavesdropping >organizations (NSA or NSA like) spending lots of money listening to >commercial traffic for a variety of reasons (trade secrets in critical >technologies, info to support trade negotiations, strategic assessments, >etc). But if the data owner doesn't think it's a risk, then the data owner >isn't going to spend the money. Often the information is accessible through >several easier channels anyway. > >However, it's important to keep in mind that lots of systems still rely >heavily on reusable "secret" passwords for authentication. This may give >attackers a really juicy target and might make costly attacks seem >worthwhile. > >Rick. >smithat_private ----- "Cryptography is like literacy in the Dark Ages. Infinitely potent, for good and ill... yet basically an intellectual construct, an idea, which by its nature will resist efforts to restrict it to bureaucrats and others who deem only themselves worthy of such Privilege." _ A thinking man's Creed for Crypto/ vbm. * Vin McLellan + The Privacy Guild + <vinat_private> * 53 Nichols St., Chelsea, MA 02150 USA <617> 884-5548
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 12:56:25 PDT