back to article Taking IT security to task

This survey is ended.


This topic is closed for new posts.
Silver badge

Dumb and Dumber still ......


The more that one analyses the Root Cause of Problems, the more one realise that the Problems are Self Made.

And then the normal course of events is to exacerbate them by denying it and thus creating more Problems. Eventually though, even the slowest of wits realises that their course of action is at fault and the Game has to be Changed with them funding the Change if they want to protect themselves from Rancour, which may very well be Fully Justified and Easily Proven.

Then the Problem becomes more focussed on Guilty Individuals rather than being hidden and hung on Innocents in the Fog. QuITe what happens then is anyone's Guess but very Few can Forget to Forgive in the Face of an Impersonal and Unimpressive Foe.


The Four Pillars


Processes (business and technical)



of which the most important is the last of these; only the (in)actions either through ignorance or malicious intent of People can defeat the measures in place in the first 3 categories.

Anonymous Coward

Security is not simple or cheap

Most exploits are run by insiders, outside crackers obviously exist, but for the main part more money is lost from the internal threat.

The problem is people are paid a comparable amount whether they work on security sensitive data, or data in which security is not an issue.

CEOs like to have access to all data, as do admins and security folk, all of them represent a possible point of high compromise, that affects a lot of information.

No one can really be trusted when the environment is competitive, knowledge is power, and power is alluring. Concepts such as split passwords, where at least 2 or 3 people are required to open the data from a pool of about 6, who then sign off that the data was not then subsequently copied is probably going to have be the norm rather than the exception. And the audit trail is the most important, which should be handled by a couple of entities. All of this costs money and time though.

Basic encrypted security, obfuscation, trust and tight audit trails of access are probably the workable solution to IT security.

Trust is the interesting one really, and that encompasses a number of elements. And this is the key reason for compromise. It is how you measure trust that is the problem. Internal compromise usually happens when some other event has occurred before to weaken trust.

The audit trail is perhaps the weakest one at the moment for IT security, of course logs of access exist, but they should be made more public, with people signing off when they accessed accompanied by the reason for access.

There is no privacy right when you are viewing other people's information, only when viewing your own. If people realised they had to account for their access, then most internal breaches would not occur, it would also help in identifying when an external breach occurs.

The other thing to realise, is that holding data can be made more of a burden than an enabler, and laws which limit data retention held on third parties are a good move to increase that burden. Some companies think it is legal to hold internal data lists on third party suppliers, grading them so others in the company can then select them later as preferred suppliers and not informing the suppliers that this data is being held. This goes against the data protection act, but it is fairly common. Credit cards are often held by ecommerce sites, to enable quick purchases later, but of course it does make the site a target, and there is a cost associated with securing that data. The law should make a compromise more expensive to those who insist on holding CC details online, to ensure people actually put in the security safeguards and are actively monitoring the situation and improving the security all the time.

As to the inside problem of security that is not malevolent, unfortunately nowadays you have to keep a shit list; record the time you said you had grave concerns about being asked to copy that database and send it via mail, all unencrypted or encoded with some so called encryption algorithm, or when you asked the client if they wished to ensure that tainted data could not be used as an injection attack on current known vectors, and they said, 'no, just get the project done'.

Copper nicker policy really, let them be insecure, but make sure you record when it occurs and the fact you advised against it. If you are too obtuse and you lay down the law, then it makes it hard to operate in business.


boo hiss! spelling in questionnaire

very last question: defense



It depends

Do you mean threat to IT assets (e.g. poorly educated users opening the door to malware, etc), do you mean threat to informational assets by poor implementation of policy (like HMRC), or do you mean threat to informational, monetary or other assets by malfeasance ?

The threat profile is different in each case, and when you get to the malfeasance end of the spectrum virtually all your threat actors are going to be insiders, since they already have access to company data, resources and procedures.

Typically, outside actors can be constrained (and largely mitigated against) by almost purely technological measures which can be centrally administered by your IT folks, whereas threats from inside actors require security polices to be implemented, followed, enforced and regularly audited for effectiveness. This has to take place across your entire organisation.

Basically, since it's easier to mitigate outside threats, insider threats should have a higher weighting in your threat model.


This post has been deleted by its author

Thumb Up

Re: Start with people - and protect them

Agreed. I find it interesting the number of bad decisions that my boss has made verbally, but when I ask for the instructions in email, they never come - and the requests for status stop as well.

Note that I don't just ask for instructions for bad choices, although I don't do it with all of them. For example, when I was told my highest priority was to help some coworkers get their server code under revision control, I didn't request that to be in email. When it turned out they had no computer for the revision control repository, I made certain to get email authorization to make use of a related group's revision control repository server. The first choice was not, IMHO, a security related thing. The second, on the other hand, clearly was.

Now I just need to get a good filing system for these, and need to perfect my ability to tell *when* I need the email trail...


You should work in a bank...

...its harder to patch our servers from the inside than it would be to break in from the outside and patch them.


I've always said that. . .

A large part of IT security is, "Protecting your assets from your asshats." Your security is only as strong as your stupidest or most disgruntled user.

This topic is closed for new posts.


Biting the hand that feeds IT © 1998–2017