General discussion

  • Creator
  • #2259106

    How due diligence can get you in trouble.


    by the admiral ·

    Well, I finally did it. I got mad. Not mad at the world, mad at the security representatives, and I told them what stop they get off. Why? Why would someone like me tell someone who is well versed in security where to go? Four reasons, really.

    In our company, we have databases for everything. In fact, when someone has a new idea, they create a database. We have gotten so database centric that I simply stopped using the databases. Why? For security, we have FOUR databases, and from that list of databases came additional databases to talk about the databases that we had. Then, because of the sheer number of databases, we had databases that tracked those databases, and well, from the four, they reproduced like rabbits to 36 databases. One for the original database to track the servers, the second to ask for changes to the database, the third to track those changes in the database, and we can continue on until we now have 10 databases per database easily. Too many databases for me to track ? and then I get notification that we now have a series of databases to track information by site. And that they are documents that are auditable and that the division?s folks in another state failed against the documents. It is maddening!

    One day last week the security rep for the site stopped by my office and asked me why I have not entered my systems into the database. They were. He also asked my why the rooms were in the database. And I let him have it. First, the documents that are in the database are fluid, and that they are always in constant change as with anything in life. When I put a document into the database, once I hit the submit button, my access to the document is restricted to Read only, but yet my name stays on the door. So I said that if my name is on the door and I can not go in and change the document when it needs to be changed, it is an audit failure because I can not show due diligence. So Rather than fighting over a broken database, I keep paper records in which allows me to revalidate my security every month and review each of the entries and make the appropriate changes as needed. On every occasion, since I can show that I perform the appropriate audits according to the company security document, I pass; everyone in the database has failed. Yes, I have told them on at least six occasions that it is broken and their response only backs up their lethargic ideals. It is Maddening!

    My second problem is that with all of those databases, it becomes a full time job keeping track of the information that is in them. Rather than having to make one change and have it be distributed to the systems, none of the databases talk to each other. So while one of the documents is wrong because you can?t get to that database that day, all of the others may be right or wrong that day as well and you are audited against that document. So you either pass or fail due to that problem. So I have taken all of my information offline and store it in a book. That book keeps the information that pertains to us in it, and we ensure that when we have a change we update the information. It is Maddening!

    Third ? Automatic scanning tools are updated once a month and never detect new problems, but always pop up false positives. When one of your false positives is high, you?re dragged in front of a consortium to explain yourself. So we no longer keep the scans in electronic format, we print them out ? since we will have to run down to the meeting room and explain our lack of action on a high return. It is maddening that you fail by a tool that is supposed to keep information current, but when they audit you they print the record out. So why keep the records? It is maddening!

    Fourth ? All of the companies that we have OS?s on put out security bulletins a full two weeks before the actual patch. They get the patch the day it is released then play with it to see if it will impact systems. The fact of the matter is that any patches that come through that are considered critical should never have to go through the maddening process of testing for the sake of giving an over paid executive a warm fuzzy. When we take a look at how many companies do this versus viruses and worms that have their way through an entire enterprise, who cares? It does not take a brainiac a month to figure out if a patch is critical or not. Here is the scenario. Joe blow has an unpatched system that is under the watchful eye of the corporate big brother application. It does not patch because it is still in the testing stage. After the employee farts around on his personal access account he gets nailed with the virus. The next morning, the firestorm starts. He brings in his laptop and plugs it into the network, logs on and infests every single system in the network. Testing is good if you have a bunch of desktops on the network, but you are wasting your time when you have notebooks. Plain and simple. It is maddening!

    Why am I so mad? It would seem that the company can?t find a programmer that is smart enough to program the databases properly ? even after the software manufacturer gives plenty of notice update them; can?t program the databases to talk to each other, and sure as hell can?t keep updated when anything changes.

    Sorry folks ? I am taking my documentation off line ? the rest of you can fail. I have come to the crossing point now where I have to be convinced that technology has a solution, where 10 years ago I pitched that it was….

All Comments

  • Author
    • #3209004

      The technology is good, and does solve problems,

      by deadly ernest ·

      In reply to How due diligence can get you in trouble.

      and it does make things easier. However, you cannot remove the bugegr factor, the idiot factor, or the bureaucratic rectum factor. Your system sounds like it has more rectum factor than technology factor.

      Get the company to hire a decent database programer and fix it. If two databases need the same info, then they should share nicely, and auto update from the one entry.

      You may need to do something like this.

      Some years back I went to work in an area where we had a problem with several non-talkative databses and much of the same info in them. It took a long time, but I fixed it all. First I created design of each databse (none existed) listing the fields, type size etc and the way they related internally. Did this for all the databases. then I created a design for one master database design – using a relational database set up. Then I created a set of scripts to convert all the info in the existing databases into the new one. Some had to have the data change type, some change format, many changed field sizes. next step was to recreate all the existing screens for the new database. Then stage was to check that everything would input and update correctly. Since no one wanted to have THEIR database changed, I had to create a bunch of scripts that opened the new database, while looking as if they were opening the old ones. Thus all the old hierachy trees still existed (for those that used them) but pointed to the relevant parts of the new structure. Thus someone could have three or four links, from different old apps, to the very same page. I also had a new hierachy tree and script set for the new database.

      Luckily, none of the screens had the database name showing when you opened a screen.

      We told everyone that we were creating a new database that would be automatically updated from THEIR databases each night. The new hoerachy allowed for easier access and cross checking, and they were encouraged to use it.

      We did the change over on the weekend, and management chose NOT to make a public announcement about it being a total change over. Many people continued to think they were still using their old database, when they weren’t. Management managed the change by not letting them know there was one.

    • #3205791


      by jdclyde ·

      In reply to How due diligence can get you in trouble.

      Sounds like there isn’t a single person or group in charge of the information, leading to the clusterf#ck that you have going on.

      And when you get anyone throwing up any little database to do every little thing, they forget about making a SYSTEM.

      The more different databases you have, the less likely ANY of them will be accurate.

      Take two asprin and walk away. B-)

      • #3205676

        No Asprin – Advil!

        by the admiral ·

        In reply to Centralization

        I’ve gone through two bottles of Ibroprofin this week and walked away.

    • #3205774

      How in the world

      by tig2 ·

      In reply to How due diligence can get you in trouble.

      Do they manage to compliance requirements? It sounds to me like there is no credible way to audit.

      With all the databases, are you by any chance a Lotus Notes shop? I have seen similar happen in Notes environments. The trouble is that Notes isn’t relational, it’s flat. That limits its usefullness.

      Sounds to me like the right thing to do is to shred and start again. What a mess!

      • #3228444

        Manage Compliance?

        by the admiral ·

        In reply to How in the world

        What is that? They are stuck in an infinite loop, shoving paper into the auditors face and saying “See? See? We kept the precious…”

        Seriously, I don’t know – because not a single thing that they are doing is ensuring compliance or working toward it. The fact of the matter is that if they stuck with the corporate guidelines and not followed every single White paper on the market, they would find that they would have compliance and security.

        More fun than a gaggle of geese!

    • #3205772


      by jellimonsta ·

      In reply to How due diligence can get you in trouble.

      I have a website that may be able to help out!


    • #3282517

      Uno persona

      by problemsolversolutionseeker ·

      In reply to How due diligence can get you in trouble.

      There is one person in your organization that is driving this.
      Take their spot!

      Of course, ISO 200x and CMM and all that formal nonsense comes to mind. Boot it!

      Worked for a client that was seeking ISO 200x compliance. Every time we would have a meeting or a telephone conversation, some yahoo would break in asking for bla-bla documentation. At risk of losing the client, I finally told the guy to take a hike. Turns out the clients (his fellow workers), were waiting for us to do that for them!

    • #3283457

      I remember this stuff

      by gentlerf ·

      In reply to How due diligence can get you in trouble.

      From a long time ago, in a FedGov job long gone, dBase Wars. We had similar events going on in an office area where they wanted a lot of things ot be entered into a database. Some areas needed separate databases and associated application/screen/reporting code. At first, I was doing the updates for one group. Then I was “loaned out” to another since there was no definitive code maintainer for the various dBase (yes, we were using that at the time) applications and the databases which resulted. It got pretty hairy after a while when I was updating the code to include documentation of what each section of it was doing. A supervisor would come by and ask, “Is it done yet?” further exacerbating my day. I was glad in some ways when I was reassigned to another command then later left government work.

      All I can say at this point in my rambling is, may the Odd Gods of the Galaxy help you if you are working for the Government.

    • #3283345

      Similar experience

      by c_tharp ·

      In reply to How due diligence can get you in trouble.

      I see similar nonsense happening in the name of Sarbanes-Oxley. A host of rules have been put into place that require many records of any action taken, normal work procedures, updates, corrections, etc.

      There are checklists that “prove” that you did the work. The checklists are the documents that are auditted, not the actual result of the task. In other words, the core data is not examined to see if it complies, but the checklists that say you did the work are checked. Now, do you think that someone who doesn’t care about doing the work completely or correctly is going to hesitate at marking the checklist?

      An auditor will leap on anything printed. As soon as an auditor sees it, they want it archived. They want temporary documents that you use in the course of your work, even hand written notes. It is easy to see where this leads, so keep it private and dispose of it when it’s usefulness is gone. As a result of all this, I do not reveal any printed record to an auditor unless it is necessary or something that would be maintained in the normal course of business.

      Most of the work behind the rules and checklists is needed and gets done. It can be verified, so the documents add nothing of value for an audit.

      Putting the documentation on line, just adds another layer. It all has to be printed to be official.

      So, be careful of technology. It is suppose to be a tool for getting the work done. Don’t let it become an obstacle.

Viewing 6 reply threads