nav search
Data Center Software Security Transformation DevOps Business Personal Tech Science Emergent Tech Bootnotes BOFH

back to article
Someone has broken into your systems. Now what?

All good stuff but...

Reality is a bit more complex for smaller companies that cannot afford to have a person dedicated to reading and interpretating the various logs, to pay for the IDS applicances etc etc etc

And then there is documentation. Oh and of course data registers...and who owns what and the requirements surrounding the management of the data and....and....

*sigh*

Its really annoying when you know what needs to be done but the business is either not inerested or not in a position to do all these gnarly things.

1
0
Silver badge

Re: All good stuff but...

My watchguard firebox comes with IDS built in, along with alarm notification via email for things you deem to be important.

Having worked at much larger businesses, I am pretty sure my little network is actually a lot more secure than the larger ones I have worked on. I may not have as much cash to spend, but I have enough. I have a vastly smaller attack surface and can implement things that would be to difficult for larger firms to run properly without a lot of staff who know what they are doing.

1
2

Re: All good stuff but...

@ Peter2

My fail...I work for a company that is regulated by the FCA (possible that that alone is a fail rather than the omission from my original post that we are regulated)

One of the things they seem to be interested in is if we log and read the logs and what actions are taken with regards to logs. I have no talent in my team that can read logs...let alone actually get logs (proper) from our TMG. Luckily it is eol next year so I will be able to get something new but I still have the base issue of not having the skill and time to have logs read. Let alone the logs off the servers to determine who had accessed what.

All these things are not massive issues if allowed to remediate but the business does not want to spend money. There is a trade off eventually that needs to be decided upon...document the policy/process and weigh up the risk appetite.

Probably my bad luck that I am in just the wrong side of the tipping point for enterprise/small medium business ;)

0
0
Silver badge

Re: All good stuff but...

You need to generate readable logs first, too.

1
0

Re: All good stuff but...

@ Destroy All Monsters

Absolutely....

TMG is utterly shyte at that. Certainly there are thrid party plug ins to provide more indepth logging but its not "real" logging...rather extrapolations of activity.

And should one really consider software plug ins as acceptable on security systems? <-- honest question for debate

2
0
Silver badge

Re: All good stuff but...

> "My fail...I work for a company that is regulated by the FCA" [snip] "One of the things they seem to be interested in is if we log and read the logs and what actions are taken with regards to logs."

I feel for you. My industry is regulated, but our regulator basically states that they'll shut down anybody who has a serious data breach, and data breaches should be avoided by seeking the advice of a IT Professional or IT consultancy.

0
1

Re: All good stuff but...

@Peter2

Oh yeah...data breach/loss is also a big big no no and can lead to some pretty hefty fines. On top that you also have the ICO who purview is the Data Protection Act. They can also land you with some pretty hefty fines as well.

I have no real issue with these things though...and would rather like to see them tightened up further. Howeveras someone else mentioned on this thread...bosses don't care until they have been stung.

As for the honey pot discussion....ludicrous. How many small businesses have the cash and the technical know-how to implement that? To keep it running, to dea with issues arising from it? Unless you are a tech company...not fucking many.

That is the thing with the so-called security experts in the article...they are ensconced in their ivory tower pontificating but with little knowledge of the world of the small business.

0
0
Holmes

Re: All good stuff but...

The fact that SMEs find this stuff hard, and that a lot of breaches get the hashed password file, and then just brute force it (since most humans pick dumb passwords) is one of the reasons Dyadic Security created its DSM technology (http://www.dyadicsec.com/technology/). One of the main use cases is to encrypt the entire password file using probabilistic encryption, and so render such brute force hacking impossible. Of course the DSM can be used to protect all sorts of similar applications. But the protection of the password file/DB from breaches is probably the easiest to understand, and it also protects against law enforcement asking you to reveal users passwords as well by spreading the trust over many countries.

0
0

Re: All good stuff but...

@ Nigel Smart

Nice. However I can see that being cost prohibitive for SME's. Well mine anyway. If my org was bigger I would certainly agitate for solutions like this. All I can do at the moment if document and highlight risk and let the business decide its course of action. Of course I do propose solutions but the fact is that as soon as technology rears its head non IT directors eyes glaze over as the topic is of little interest. The only time I can rouse any interest is with financials which is not the easiest topic for IT to deal with.

0
0
Silver badge
Pint

Honeypot should already be in place

Miscreants should be redirected to the honeypot upon first inkling.

Should be 95% automated.

0
2
Anonymous Coward

Re: Honeypot should already be in place

How the hell do you do that?

0
0
Silver badge
Coat

Re: Honeypot should already be in place

Simple prompt like the "cookies" one.

"Are you a bad person?"

If Yes, route to honeypot.

Alternatively "Do you like honey?"

2
0
Silver badge

Re: Honeypot should already be in place

@JeffyPoooh

One might argue that if you had such a system, you have already ticked all the boxes and more.

What part of this is 'automated'? is it just the redirection? If so, what is this automation? Presumably identifying what traffic you redirect is the major part of this as it then determines how you redirect it. Is directly in from external? Can it be isolated to an IP address or range? Are they being spoofed and frequently changed? If so which device do we have to examine to pull the correct IP? Or can we only identify the traffic through deep packet inspection? Is it an internal infected machine, and thus not passing through the same security devices? A compromised user account? Is there any incoming traffic or only outbound?

Once you've identified the type of traffic, the redirection is the easier part, though of course you also need to understand what data is being crawled and siphoned so you can direct the traffic to a representative system, understanding that the analogy of the 'honeypot' presupposes that someone wants the honey.

If an intruder is after, say, database data, directing their requests to a file server without the appropriate services listening on the appropriate ports, well, that's not necessarily going to work in the intended manner. Sure, you'll stop them getting the real data but the idea of a honeypot is not just to stop but to catch, thus you need appealing and appropriate bait.

And this is non-trivial.

I find your choice of words informative: "Miscreants should be redirected to the honeypot . . . "

This implies that the honeypot is already there and thus, as per my comments above, be suitable for the task, requiring either prescience or an segmented system that is representative of your setup, including patch level and ports, etc... After all, some exploits rely on bugs introduced in NEW updates so simply having a wide open system without AV or patches is not necessarily enough.

I may be reading too much into it, but given your point is that this should be automated, I'd say it's reasonable to assume that in your scenario, the honeypot is waiting, ready to go and fit to accept whatever type of requests (such as malformed sql commands) the real system is being subjected to.

Note the language used by Von Roessing:

“You must set up a honeypot to keep them distracted, while having your forensics team secure the evidence."

This implies that you first identify the traffic and then build a honeypot accordingly, which is much more reasonable, though if this is part of a plan that has been laid out in advance, as is suggested, then some skeleton system in place should be assumed.

Still, all of this is quite expensive and can be the kind of thing that is difficult to convince the boss to approve. Many security precautions only get the go-ahead once you've already been stung.

1
0
Silver badge

Re: Honeypot should already be in place

Or just redirect based on the Evil Bit, see RFC 3514

0
0

Re: Honeypot should already be in place

@JeffyPooh

Automated? What? You just pull out a new system like that out of yer arse along with the associated policies?

Fan-fucking-tastic.

0
0
Anonymous Coward

Stuff that keeps spooks awake at night

From the article:

“You must set up a honeypot to keep them distracted, while having your forensics team secure the evidence."

How do you set up a honeypot when one of the concerns of your security team is that the bad guys are reading your security reports and listening to your telecons about the incident?

Sadly, this is not always as much of an academic a question as it ought to be.

0
0
Silver badge

"“Companies are split into two kinds: those that know they have been breached and those that don’t,” agrees Lior Arbel, CTO at IT security consulting group Performanta."

I am sure he does 'agree'.

Of course it all depends on what you call a 'breach'. If you mean some random piece of scareware on a laptop or adware browser hijacker then sure.

People should lather, rinse and repeat. agree shampoo manufacturers.

0
0

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

The Register - Independent news and views for the tech community. Part of Situation Publishing