Saving Bugtraq

In July of 2019, many noticed that the Bugtraq mail list stopped having posts approved, including Art Manion at CERT. Since there are many other outlets for vulnerability disclosure, such as the Full-Disclosure mail list, Packetstorm, Exploit Database, and increasingly on GitHub, it didn’t receive much attention. It wasn’t like the days when the list was created when there were very few places to disclose that would be seen by other security professionals and hackers. Despite that, the list has a long history and many came up in their respective scene recognizing what it represented.

The last post to the list, as of now, is dated July 26, 2019. In December of 2019 I tweeted to SecurityFocus and Symantec, its parent company at the time, asking if they had killed the list. I received no reply. Months passed and I got curious again, so I reached out to both companies via email trying to ascertain the status of the list. Two of the three public addresses I found on their website immediately bounced as undeliverable while the third went unanswered. I shared that update with Twitter as well in May.

After the last Tweet, someone reached out and offered to help me figure out the disposition of Bugtraq. We started chatting in May and they went to work. You may think this would be a relatively simple task and it would be for smaller companies. However, remember that while Symantec acquired SecurityFocus back in 2002, Broadcom acquired Symantec in November, 2019, and then Accenture acquired Symantec from Broadcom in April, 2020. You can imagine the amount of chaos going on in that organization and the layers of management along with the vast number of departments.

During that initial chat, I said “a lot of people don’t want to see the Bugtraq list just vanish given its history. We’re hoping Broadcom starts it back up or will pass it off to someone else in the industry to run.” That same day my contact figured out the general org structure involved and where to start asking around. A couple weeks later they reported back that it fell under an Accenture business unit, that there was discussion going as to the disposition, and that the pandemic was slowing things down. Jump to August, 2020, and they reported back that they were still working on it and that “breathing life into [the list] might be possible”.

In August, before they checked in with that update, I had decided to update the Wikipedia entry for the Bugtraq list as it was pretty sparse originally. I added a significant amount to better document the history around the list as well as some highlights like some controversies. My contact said those updates were actually helpful in gaining traction which I thought was cool. Nay-sayers about Wikipedia take notes! A few months passed and my contact reached back out in November with an update saying “I have a bit of an uphill battle here”. Giving it back to the community was being discussed, but we both immediately realized the next challenge if that happened; who would run it. No chance in hell I would. I said that if they posted to the list asking, I am sure they would get many volunteers. Vetting those and figuring out a viable long-term option might be tricky though.

In January, they messaged again saying “I have a few battle scars and ultimately lost the fight for [it]”. That was almost at the same time that I read the January 15 shutdown message that was posted to the list. I was one of several that Tweeted about it, lamenting about the loss.

I sent another message to my contact thanking them for fighting for it, and that I was happy a clear message had been sent finishing off the list. There was some concern about the possible fallout for the team, and that they “still remember hiring folks who said their goal was to be referenced on the Bugtraq list.” That was a great reminder that today claiming CVEs is some misguided notion of skill while back then, getting a post to Bugtraq approved meant a lot.

We continued the conversation on January 16 and they cryptically told me “there may be hope yet”, citing a ZDnet article that apparently got the attention of some executives. I joked with them saying “that would be an epic unintentional troll, if it got resurrected weeks later” to which they agreed. The list admins allowed one response to the post through that day, a shout-out from the old-school hackers of UPT. A day after that, the list admin sent a mail titled “On Second Thought…” stating that based on feedback, they have “decided to keep the Bugtraq list running. We’ll be working in the coming weeks to ensure that it can remain a valuable asset to the community for years to come.” Accenture followed that up with a more lengthy blog about the list revival.

Here we are months later and I thought back to part of our conversation in which I told them I “wish people knew just how long you had to fight on this and how much of a hurdle it was just to post the list.” They said it was probably a story best told over a beer, or something harder, suggesting I probably don’t know the half of what they went through to get all of this rolling. So I wrote this blog with the hope that they said it was ok to post, to share the story. InfoSec is full of heroes that work behind the scenes, fighting the good fight, and trying to make things a bit better. They deserve more recognition than they get. This is just one example of that. So thank you, so much, for your work in helping keep the historic list alive.

Your yearly reminder to post to Full-Disclosure, not Bugtraq

[This was originally published on the OSVDB blog.]

[10/29/2020 Update: As of February 24, SecurityFocus has stopped moderating posts to the Bugtraq mail list without explanation or warning. This is apparently related to Broadcom acquiring Symantec, the owner of SecurityFocus.]

This has been a long-recognized and proven thing, but every year we run into more glaring examples. SecurityFocus, who runs the BID database, which is part of Symantec’s DeepSight offering, routinely uses submissions to the Bugtraq mail list to seed their commercial database, sometimes days before approving the post. This means subscribers who use Bugtraq as one of many sources of ‘real-time’ vulnerability intelligence routinely get the short end of the stick. Full-Disclosure, managed by Fyodor and team, do not have that commercial interest in the content of the posts to the FD. Their average turnaround time seems to be considerably better in approving posts. So please, for the industry’s sake, post to Full-Disclosure and stop supporting Bugtraq.

Today’s example: A new CVE popped up in various places. Google showed the first hit to be the BID Database:

EMC only posts their advisories to the Bugtraq list, so we checked there first, since that would be the provenance:

There are EMC advisories visible, but not the one with CVE-2017-4985. Checking again today:

SecurityFocus delayed the post by three days while it was in their database.

VDB Relationships (Hugs and Bugs!)

[This was originally published on the OSVDB blog.]

Like any circle in any industry, having good professional relationships can be valuable to involved parties. In the world of security, more specifically Vulnerability Databases (VDBs), the relationships we maintain benefit the community behind the scenes. Like ogres and onions, there are layers.

Someone from CVE and someone from OSVDB run an informal list called ‘Vulnerability Information Managers’ (VIM) for discussion of vulnerabilities as relates to post-disclosure issues. New information comes up, additional research, vendor confirmations, vendor disputes and more. It’s a great resource for us to discuss the details that help each VDB fine-tune their information. (No new vulnerabilities are posted there, don’t bother)

In addition, some of the VDBs have stronger relationships that allow for great dialogue and information sharing. A few examples of these, from OSVDB’s perspective:

– A couple of the CVE guys are great for very informal chat about vulnerabilities. Despite being the dreaded “government contractors”, they are respectable, very knowledgeable and have a great sense of humor. I just sent one a mail with the subject “PROVENANCE BITCHEZ?!” challenging him on the details of a given CVE. They are so nice, I broke my rule of not taking candy from strangers and happily accepted the bag of leftover candy from their BlackHat booth. Joking aside, the ability to coordinate and share information is incredible and a testament to their integrity and desire to help the industry.

– OSVDB uses Secunia for one of our feeds to gather information. The two guys we regularly have contact with (CE & TK) lead a bright team that does an incredible amount of work behind the scenes. In case it slipped your attention, Secunia actually validates vulnerabilities before posting them. That means they take the time to install, configure and test a wide range of software based on the word of 3l1t3hax0ry0 that slapped some script tag in software you never heard of, as well as testing enterprise-level software that costs more than OSVDB makes in five years. Behind the scenes, Secunia shares information as they can with others, and there is a good chance you will never see it. If you aren’t subscribed to their service as a business, you should be. For those who asked OSVDB for years to have a ‘vulnerability alerting’ service; you can blame Secunia for us not doing it. They do it a lot better than we could ever hope to.

– The head of R&D at Tenable contributes a lot of time and information to VIM based on his research of disclosed vulnerabilities. Installing the software, configuring, testing and sometimes noticing additional vulnerabilities. He is a frequent contributor to VIM and has worked with OSVDB on sharing information to enhance the Nessus plugins as well as the OSVDB database.

– str0ke, that mysterious guy that somehow manages to run milw0rm in his spare time. What may appear to some as a website with user-posted content, is actually a horrible burden to maintain. Since the site’s inception, str0ke has not just posted the exploits sent in, but he has taken time to sanity check every single one as best he can. What you don’t see on that site are dozens (hundreds?) of exploits a month that were sent in but ended up being incorrect (or as OSVDB would label, “myth/fake”). When str0ke was overwhelmed and decided to give up the project, user demand (read: whining & complaints) lead him to change his mind and keep it going. Make sure you thank him every so often for his work and know this: milw0rm cannot be replaced as easily as you think. Not to the quality that we have seen from str0ke.

Since we have no corporate overlords, I’ll go ahead and talk about the flip side briefly:

– ISS (now IBM) runs a good database. Very thorough, keen to detail on including original source and vendor information. In 2004, the head of that group (AF) left, and until that time, we had a great dialogue and open communication. Since then, even before the IBM frenzy, we’ve mostly gotten the cold shoulder when mailing. Even when pointing out problems or negative changes on their side. LJ, bring back the old days!

– NVD. Why do you waste taxpayer money with that ‘database’? We pay $22 for Booz Allen Hamilton to “analyze” each CVE entry (thanks FOIA request!), yet they find a fraction of the typos and mistakes I do? By fraction, I mean exactly none from what I hear through the grape vine (DHS cronies are cool). If you can’t notice and report simple typos in a CVE, and you botch CVSS2 scores left and right (yes, I’ve mailed in corrections that were acted on), what exactly are you doing with our money? Are you the virtual Blackwater of VDBs?

– SecurityFocus / BID. Sorry, not going to bother with verbal fluffing. My countless mails pointing out errors and issues with your database are seemingly dumped to a black hole. Your promises of certain mail archives ‘not changing’ were pure fantasy. To this date you make erroneous assumptions about affected products, and still don’t grasp “case sensitive”. I know some of your team, you have great people there. Just lift the corporate policy that turns them into virtual shut-ins, please?

Sorry to end it on a downer. I still dream of a niche of the security industry (VDBs) where we can all play well with each other.

The Upside to the Provenance Problem

[This was originally published on the OSVDB blog.]

As mentioned before, Christey of CVE mentions an ongoing problem in the vulnerability world is that of “provenance”, meaning “where the hell did that come from?!” Vulnerability Databases (VDB’s) like CVE and OSVDB are big on provenance. We want to know exactly where the information came from and include it in our entry. Other VDBs like Secunia or SecurityFocus’ BID are bad about it. That is to be expected though, we’re talking free/open vs commercial/closed. BID/Secunia gain some value by appearing to be magical when it comes to finding vulnerability information.

For anal retentive freaks, the provenance problem does have one upside. For years now, OSVDB has been aggressive in digging up vulnerability information, regardless of age or severity. This typically means spending hours upon hours of reading changelogs, which usually are not the most stimulating reading one can find, and more often than not lack any form of clarity or simplicity. This also means relying on a bit of guesswork at times, as changelog entries tend to be short and sweet, leaving a lot to the imagination. One such example is the recently published Empire Server Unspecified Vulnerabilities from Secunia. As always, unspecified and no reference as to where the vulnerability information came from means looking at the vendor site, bug tracking systems, news archives, changelogs and more. An hour after digging, I still can’t find where exactly Secunia got “Some vulnerabilities with unknown impacts have been reported in Empire Server. The vulnerabilities are caused due to unspecified errors in the game server.” One of the OSVDB manglers (mdodge) was able to track down where this information came from while I was knee deep in changelog.

Despite that, OSVDB will soon have as many as 12 more entries for the Empire server from other Changelog entries, and I’m not even 10% done reading. I’m conflicted here.. part of me is sad, because the only other previous entry OSVDB has for this is an old entry dating back to 1981 and nothing since. That is depressing in the world of VDBs, and a discredit to what we do. Consider the entries in various VDBs: CVE 0, ISS 0, ST 0, BID 0, Secunia 1, OSVDB 2. Yet the changelog for the 4.x branch suggests over a dozen vulnerabilities?

The other part of me is happy as this is one more product that will be better represented in a VDB as far as security goes. People want better vulnerability trending, a more accurate vulnerability history and a better idea of a product’s security. That won’t happen without a more complete picture of the vulnerabilities in a given product.

Security Advisories, Mail Lists, and You

[This was originally published on the OSVDB blog.]

When a security researcher finds a vulnerability, they may choose to release the details in a formal advisory. The different between a random post to a mail list and an advisory typically involves the level of detail and the amount of peripheral information to the vulnerability. This includes discovery date, vendor communication timeline, patch information, formal writeup and technical details of the vulnerability. Because advisories are used as marketing material as much (or more) as vulnerability research/disclosure, some security companies would rather use them to attract attention to their web site.

To do this, they may post a brief message to a mail list announcing the discovery of a new vulnerability and a link to the advisory on their web page. This may seem logical and understandable, but in the long run this does a huge disservice to the security community. What happens when the security company goes out of business or gets purchased by another company? Overnight, all of their advisories and research may disappear. Mail list archives will then contain no useful information and a dead link to a site/advisory no longer there.

This problem (and debate) goes back a ways, most notably in 2000 when Elias Levy (then moderator of Bugtraq) rejected a post from @stake because the vulnerability report did not contain enough information. Thomas Greene covered this incident and dug into the issue. Levy later cited his reason for rejecting the post, which touches on my previous post:

“For very long we have tolerated the marketing copy on vendor advisories because while annoying they were accompanied by useful information. But in this change there is no value added to list subscribers. It’s for this reason that we are not accepting such advisories,”

For those of you who side with companies that post glorified advertisements without technical details, consider the following quote from Levy:

“I’ve asked the list subscribers for their opinions. I’ve received over five-hundred messages to far. While a handful of people liked the notices, the large majority of them, probably around 95 per cent, found the change to be a negative one and want me to hold firm to the policy of not approving them.”

The ultimate irony here is the Levy work[s|ed] for SecurityFocus, who was purchased by Symantec, who also recently purchased @stake and subsequently removed the @stake advisories from the web site a few weeks ago.

Mail List Archives 101 (or Why SF Hates VDBs)

[This was originally published to the OSVDB blog.]

Running a mail list archive is a straight forward task. Collect, organize and make mail list posts available via the web. You can see such archives at seclists.org or the Neohapsis arhive. Most folks that use archives like this have their favorites for various reasons. Speed, the lists they archive, or the organization usually. Most archives use a system where the URL to the post is logical and somewhat informative. Looking at the URL to the latest Bugtraq post archived at Neohapsis:
http://archives.neohapsis.com/archives/bugtraq/2005-10/0259.html
. We see the mail list name, the year and month, and a unique number for the post. Bugtraq, 2005, October, 259th post. Simple and easy!

SecurityFocus maintains an archive of the mail lists they run. Until a couple months ago, they used a scheme that wasn’t very informative. A sample URL http://www.securityfocus.com/archive/1/245152 shows it doesn’t help us discern anything about the post. Annoying, but oh well, most people could live with it. A month or two ago, SecurityFocus decided to revamp their system which would also impact their entire archive. They made assurances that the changes would be transparent and that old URLs would work. As I predicted to one SF employee, it didn’t work out so smooth, and many of the old URLs did not translate properly. At first he doubted me, then asked for examples. After providing half a dozen he saw that it wasn’t a fluke and that something had gone wrong. Unfortunately, whoever he shared that information with didn’t act on it. What is more annoying, and more damning, is that SF implemented a new scheme that is just as bad as the old one. Look at an example of their new scheme:
http://www.securityfocus.com/archive/1/414100/30/0/threaded
. This URL doesn’t tell us anything about the mail list or post either.

Why does this matter? There are hundreds of Nessus plugins that reference these old URLs, and in some cases only reference mail list posts, via the SecurityFocus archive. Clicking these now leads to .. no information. There are also countless CVE entries that reference the old URL scheme. If you want to see the original point of disclosure, you are forced to visit another database (that competes with SecurityFocus) such as ISS X-Force or OSVDB to see a valid link, as they choose to reference mail list archives that are more friendly to users.

In short, if you maintain a security product or database, please do not reference SecurityFocus or any other archive that uses an obscured scheme, or has intentions of changing their scheme.

The Last Line of Defense, Broken

[This was originally published on SecurityFocus and mirrored on attrition.org.]

The Last Line of Defense, Broken
The Public Perception of Security Companies Getting Compromised

Every so often, the protectors of your most important digital resources get hit with a little mud in the face. The so-called last line of defense is broken, and the security company protecting your networks falls victim to the ones they work against. It happens, possibly more often than you realize, and it will continue to happen.

The question to ask is what can be gleaned from a network security company getting hacked. Does it adversely affect business and undermine the trust and confidence customers place in them? Or is it fair warning that anyone is vulnerable to attack and a grim reality we must face in today’s networked world?

Perhaps it is a little of both.

Security companies are there to offer security to companies lacking the ability to protect themselves. Further, they are the publicly-perceived experts in all things security related. Their software, consulting services, and superior knowledge of computers are but a small part of the arsenal they use to keep malicious intruders
out of your networks. At what point do these resources break down and allow someone to compromise even a security firm’s security?

The Race Condition

Those familiar with the technical side of UNIX security may recall many older exploits that relied on winning a Race Condition to achieve increased access. The concept of these attacks are that the program must beat the system in performing a specific function or task. If the exploit successfully beats the system to this target
function, it is able to gain elevated privileges giving the intruder more control over the system. If it fails the race, nothing extraordinary occurs.

Much like the Race Condition attack, security companies and intruders are in a continued Race Condition every day. Each day the security companies stay secure, they are winning the race. Every day a security
company is hacked, they have lost another leg of the race. Both hackers and security professionals are looking for new bugs in software and operating systems. Sometimes this entails elaborate testing against poorly documented software while other times it is detailed scrutiny of tens of thousands of lines of source code.

The entire time this race is going on, security companies are also creating products that will hopefully protect them against entire classes of attacks. This effort is designed to attempt to protect them from the unknown, namely the undisclosed vulnerability that hackers have discovered before they do. These forms of protections are currently found in the form of firewalls, intrusion detection systems (IDS), and other specialized security software.

Perception is Everything

Back to the original question of perception of these incidents. There are two ways to perceive a security company failing in their own specialty:

    1. The compromise of their network adversely affects business.
       The incident further undermines the trust and confidence
       their customers place in their ability to secure a network.

    2. The compromise is fair warning that anyone is vulnerable
       and that there are simply too many undiscovered bugs out
       there. No one can reasonably expect security companies to
       find them all.

Life has taught us that things are not that simple. Our perception (should be) based on more than the event of the hack. Rather our perception should be based on the hack and more importantly, the company’s reaction to the incident. There are two basic ways a security company can react to an intrusion of their own network (assuming it is publicly known):

    1. Admit there was a lapse in their own security and a network
       intrusion occured. Water under the bridge and a pledge to
       do better.

    2. The government way: cover it up. Disavow! Never happened!
       If no customers know (or more to the point believe) an intrusion
       occured, then there is no loss of integrity and disaster
       has been averted.

As logical and honorable as it sounds, not all security companies will admit to incidents that hurt their reputation. The downside to this course of action is when the public does find out. Like all things political, it escalates the incident into an embarrassing failed coverup worthy of tabloids.

Because many people believe admitting such things is automatic grounds for laughter and snide remarks, they take the low road and cover up.

Rather than lie or attempt to obscure prior incidents, these companies must learn that it is a fact of life and they need to move on. Use these times of turmoil as motivation to achieve better security for them and their clients. Turn the negative into a positive.

Track Record

Some readers may be trying to think of what security companies have been victims of this and have had to deal with this. In the past year, each of these security sites have been publicly defaced:

Network Security – http://www.networksecurity.org
Secure Service – http://www.secure-service.org
Securities Software – http://www.securitiessoftware.com
Secure Transfer – http://www.secure-transfer.com
AntiOnline – http://www.antionline.com
Security Net – http://www.securitynet.net
Network Flight Recorder – http://www.nfr.net
Symantec – http://www.symantec.com

Companies such as NFR who design Intrusion Detection Systems are particularly vulnerable to reputation damage over such incidents. Sites such as AntiOnline that continually boast about their own security
often find such defacements more embarrassing as well.

Worse Than Being Attacked

Yes, security companies face one thing worse than being hacked and having their web page defaced. The rumor of getting hacked. Once rumors get started, people demand answers and often won’t settle on an answer until it is the one they wish to hear. Conspiracy-driven minds will not believe the truth no matter how many times it is told. This suspicion is often fueled by prior incidents in which companies have attempted to cover up intrusions.

If SecurityCo Inc. has been talked about and rumors are floating around they were defaced, they are in a horrible position. Even if they respond truthfully and tell their customers they remain secure and have not
experienced any network intrusions, some people will believe it to be a coverup. Despite there being no proof a company was hacked, no mirror of a web defacement and nothing more than “I heard”, people often cling
to the idea of it.

FIN

The act of a security company getting hacked and possibly defaced can be damaging, it’s true. However, lying or trying to obscure such incidents can be much more damaging. If a company that created your best lines of defense gets hacked, understand that the security game is not an absolute. Everyone is vulnerable at one point or another. What should we think about our protectors falling victim? The choice is up to you but remember: no one is perfect.

How to Get A Real Security Budget

[This was originally published on SecurityFocus and mirrored on attrition.org.]

There you are, a highly paid professional administrator for a large Information Technology (IT) shop. Responsible for dozens, sometimes hundreds or thousands of machines that process company business;
business in the form of vital correspondence between Research and Development, financial transactions for your countless customers. Perhaps your systems also manage the entire payroll system of a fifty-thousand employee outfit: all things deemed important and sensitive by everyone from the janitor all way up the food chain to the management.

So if management considers those resources and income so valuable, why won’t they allocate more than a couple rolls of pennies for you to secure the networks you are there to run and protect? Worse, why do you receive the brunt of all heat when any security mishap occurs? The age old Corporate 22 (AKA, Catch-22): secure all of our networks, but you get no resources to do so, yet you will be blamed when something goes wrong. Good luck!

The Trick
So how do you get the budget or resources required to do your job? The trick is to provide hard evidence of insecurity that you can readily show to your boss. Often times administrators are given a small budget to achieve their goals. The trick is not necessarily using that limited budget to work miracles on your systems. The trick is turning that limited budget into real money. This is a gamble of sorts, but it is a safer bet than most.

Despite what you may have heard, penetration testing/auditing serves several good uses. Many people already know it can be a valuable method of testing network security and showing weaknesses in a corporation’s access points. However, this audit doesn’t need to come in the form of a six figure/six month ordeal. Hiring a team to do a quick audit can be much more effective.

Secure a reliable and talented penetration team. Define the scope of their test to include ONLY the resources you are responsible for, lest other administrators in the company deem the probes as genuine attacks. Further qualify that the team’s goal is to take some kind of trophy from the servers rather than leave a fingerprint. (1) Suggest a trophy such as a portion of a restricted database, headers to your CEO’s email, or your customer’s credit cards. There are two qualifications to this advice:

    1) Make sure this measure is approved by management in advance.
       Sniffing the CEO's email before it reaches him could prove
       risky to your career.

    2) Make sure the CEO will recognize the trophy as sensitive.
       CEO's don't care about theory or technology; they care about
       concrete, quantifiable items.  Company assets and company
       secrets rank high on that list. And handing your CEO his
       own words written to his senior management will certainly
       open his eyes.

If this is within the realm of your existing budget, explain to the team your goal. Their report should be written in a clear and concise manner as usual and indicate nothing about your secret agenda. The report should be accompanied by your own letter or paper introducing the team’s report. Who they are, why they performed the penetration audit, and the results. And should your CEO not comprehend the ramifications
of the report, your letter should go one step further and qualify the report; particularly how it specifically applies to your company. It is important that your letter and the audit team’s report do not exaggerate the
problem. As much as possible, let the facts demonstrate the issues and their severity. Most importantly, keep the report positive. Management does not like doomsday prophets and whiners!

Make proactive security a more-bang-for-the-buck sale. CEOs understand revenue; they understand revenue loss; and they understand revenue enhancement. Pitch security as that canonical ounce-of-prevention that
will save them untold dollars in the long run. If you must, give them a “you-can-pay-me-now-or-pay-me-later” pitch. Nothing drives home the point of how small the cost of a full security makeover pales in comparison to the recovery from an institution-wide intrusion.

Your friends

Security Professionals as Validators:

If your current budget is too tight to allow a penetration audit, you still have another option. The same security team can fulfill the same role by writing an assessment report based on information provided
by you and your staff. Instead of having the team find all of the information on their own, give them vital information about your network, trust relationships, firewall rules and more. From these details, the team
can piece together a good idea of the security posture of your network. From that picture, recommendations and concerns may be addressed. In many cases, your technical staff can write up the paper detailing the
network. At that point, use your small budget to get outside professional validation of your own assessment report.

Be careful, though. Politically-entrenched know-nothings in the CIO’s office may not take kindly to your actually consulting with people who actually know their Information Technology. There’s a fine line to walk in securing your system and burning as few bridges as possible.

Corporate Legal Staff:

Yes, lawyers can be your friend! Approach the company lawyers with your intentions. Illustrate your concerns and your goals as a basis for their help. Quote examples of how insecure networks can lead to
corporate liability lawsuits (2). At this point, the legal staff should be quite interested in what you have to say. In essence, you are making the legal staff part of the responsibility for maintaining a secure network.

Cover Your Assets:

Document EVERYTHING. Write memos, file reports, issue advisories, the works. If you don’t write it down, it didn’t happen. Keep a record of where you’re right and where you’re wrong. You can bet your detractors will keep the latter record, so you’re going to have to be your own champion. Even the most stern resistance from upper management can be worn away when a history of correct conclusions is brought to the fore. In short: nothing speaks like being right. If you see something dire coming down the pike, document it. If your cautions are ignored, keep hold of the documents until you’re vindicated. (I have a way of re-issuing memos authored years before, prefacing them only with a one line note which indicates that the attached document is a reiteration of cautions issued years prior. That has an unusually powerful effect.)

If All Else Fails…

Sometimes you may not have the resources to hire an audit team to help prove your point. In that case, fall back on the same tactics I use to attempt to help everyone else out there. Use your creative writing to persuade your boss you need more resources. Rather than a technical audit report, resort to at least a two-page paper outlining the same things the report normally would. The advantage to this method is that you get to use a bit more flare, a bit more creativity and scary proposed situations to help get your point across.

It’s not a matter of stretching those few dollars to accomplish the impossible. We all know that most IT shops are not given adequate resources to fulfill the requirements placed on them. With security becoming an ever popular buzzword thrown around by management, it will continue to come down on you.


Thanks: Carole Fennelly, Jay Dyson, Dale Coddington and Space Rogue for suggestions and editing. Thanks to B.K. Delong for the  URL and reference material.

Footnotes
1. Many penetration teams will touch a file owned by root/administrator
   in a restricted directory in order to prove they gained access. 

2. http://www.idg.net/crd_1998_9-70162.html
   German Court Ruling Another Blow to U.S. Encryption Standard