Partager via

All change - From debugging to security

  • Article

I am back – and sorry to have been away for so long.

 

It has been a bit of a busy time since I last blogged and I would like to explain some of the things that I have been doing since last year

 

I no longer work in developer support although I am still in the global technical support centre. However, I have been retraining and I am now working as a security engineer. It has been an interesting journey and there is more to learn; there always will be.

 

Here in PSS security, we handle an interesting mix of things. There is some product support for products such as Right Management Services (but not Retail Management Services which is unrelated despite sharing a TLA), Windows Defender escalations, Forefront Client Security and MBSA (Microsoft Baseline Security Analyzer). However, a great deal of our work is what we call incident response – that is to say hacking and malware in general. This can get quite exciting because it is time critical and we are often working with a very incomplete set of facts. Malware writers are very bad at documenting their code and sometimes we have to investigate what the tool or worm or whatever is doing which can be fun in a rushed and scary kind of way.

 

There are of course some things that we don’t do and some things that I won’t do. We don’t:

 

Do forensics. That isn’t our job. We will try to work out how you were compromised so that you can avoid it happening again but it isn’t within our remit to discover who hacked you or why. We will share what traces we find but if you need more than that then there are specialist firms who use tools approved recognized by the courts. Our focus is on getting you up and running and secure.

 

We don’t test your software or setup. Again, penetration testing is not within our remit and there are specialist firms who will do this for you. You may not have come across the term (often abbreviated to Pen testing) before but it is basically paying some people that you trust to try to hack your network. Of course, there are plenty of people who will attempt to hack your network for free but you probably can’t trust them. We will under some circumstances advise you on where you are vulnerable but that would be an advisory service agreed up front. I am sorry but I really can’t do it in this blog and you wouldn’t want me telling people about holes in your system in a public venue like this anyhow.

 

We don’t provide sample code to attack vulnerabilities either. There is a name for people who do that.

 

We will never give specifics of particular customers and nor will I in this blog. If ever I describe a situation which affected a large car maker in Germany, you can be sure that it wasn’t a large company, they didn’t make cars and they were not in Germany. I will never mention that sort of thing at all if I can explain the point without that.

 

We will not discuss security vulnerabilities or future updates any more than the MSRC blog (https://blogs.technet.com/msrc/default.aspx) does. If you ask us, we will tell you exactly what it says on that blog or just refer you there. If it says nothing there, you know that we will tell you the exact same thing. That applies to asking here or raising a case. When we have information that we can share with the public then we will be sure to make it public. Until then, I am sorry… we have nothing.

 

What I will be doing here is talking about what sort of things the bad guys (blackhats for short) have done recently – trends when I see them. If there is some additional information that I can share, I will share it just as I did when I was talking about debugging.

 

So, to ease you established readers (if any remain) in to this new topic, I will be talking about secure in my next entry. See you there!

 

Mark

Comments