Unconfigured Ad Widget

Collapse

Announcement

Collapse
No announcement yet.

Security Patrol: Why Is Security Avoided?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Security Patrol: Why Is Security Avoided?

    ** This thread discusses the article: Security Patrol: Why Is Security Avoided? **
    ** This thread discusses the Content article: Security Patrol: Why Is Security Avoided? **
    0

  • #2
    Security Patrol: Why Is Security Avoided?

    ** This thread discusses the article: Security Patrol: Why Is Security Avoided? **
    Here are some other reasons why security is avoided: - Serious security breaches are rare. - Thus, there is no political payback to to chief I/T manager to divert resources to security. - There is the risk of system disruption if a security change is implemented causing political risks for the I/T chief. - Programmers seem so trustworthy and so much more productive with *ALLOBJ authority. The above are reasons I have encountered.

    Comment


    • #3
      Security Patrol: Why Is Security Avoided?

      ** This thread discusses the article: Security Patrol: Why Is Security Avoided? **
      There is another major reason for avoiding security that has not been covered in the discussion thus far. Many organizations are using canned software packages these days. I would venture to say that this is a majority of all companies/organizations. As a licensee, you essentially buy into a whole solution, and that includes a security model. It is highly problematic to then go and attempt to retrofit the vendor's security model. This is essentially customizing the package and that's what most organizations want to avoid. This is a fundamental reason why 3rd party solutions were selected in the first place--custom development, and custom code, places burdens on the organization doing that work. It gets worse. Even if you decide to take on the responsibility of customizing a vendor's security model, that vendor may then begin withdrawing support because "you've customized our software. We don't know what you have done." At the very least, you will probably wind up paying them for any problems introduced by your security changes. The bottom line is that a security model is purchased along with everything else that the 3rd party software is. It's rarely a significant factor in the purchasing decision, but it ought to be. You are generally better off trying to persuade the vendor to upgrade that security model. That way the entire customer base can benefit from the security upgrades. This is true even if it takes years, and many revisions and user group meetings to accomplish. This also defuses a common managerial suspicion that "IT wants to do something else that won't pay off."

      Comment


      • #4
        Security Patrol: Why Is Security Avoided?

        ** This thread discusses the article: Security Patrol: Why Is Security Avoided? **
        The greater the exposure, the greater the need for security. The corollary would be "The less the exposure, the less need for security". Believe it or not, there are still many AS/400 and iseries installations where exposure is not much of a concern. For example, I recently finished a project at one client where an AS/400 was used to write software for another client. I was the only person to use the machine at this installation. There were no comm lines, no internet access, and the box was in a secured room. - - I set the security level to "10". This proved to be adequate. Even the most malicious act would have been recoverable. There was no data sensitivity question, and it never became an issue. At other installations with 30 or less users, I have survived with a security level of "30". In one shop a junior auditor got up on his security bandwagon, so we implemented greater precautions normally found in much larger installations. The complaints were then forwarded to the senior auditing partner, and all was soon set back to normal. Dave

        Comment

        Working...
        X