LinkedIn ethics

[TL/DR version: Is it ethical to "connect" with an interviewer on LinkedIn during the hiring process?]

As a professional and a contractor, my name is my most important asset. So therefore ethics are everything to me. This is especially important because of the fact that I am an Information Security professional and usually have access to information that is confidential. I need to be trusted.

When I first started with LinkedIn, even if I knew all of the interviewers for a job application, I wouldn't look at their profiles. I could - but I wouldn't.

Eventually, after reflection, I did look at their profiles but wouldn't refer to anything in them lest they think I was spying on them.

More recently, it has become so normal to "research" the interviewers to the point that if you don't look them up in LinkedIn then you are seen to be uninterested. Some employment agencies actually supply the LinkedIn profiles or URLs as part of the job specification.

My question is simple - is it encouraged/discouraged/ethical/unethical to send a LinkedIn Connection request to an interviewer? When is good to do it? Is it unfair advantage? If you land the job, could it be seen as cronyism? Or is LinkedIn professional enough that your contacts are not necessarily your friends.

If the interviewer accepts, what is the protocol? Can you talk directly to them while they are deciding on the position? Should you take that opportunity to talk to them maybe making yourself more human and more of a person than a "candidate"?

Many articles on "how to land that perfect job" (on LinkedIn, it is usually "X things you are doing wrong in job interviews and how to fix them") usually promote the idea of a "follow up" which cements you in the interviewer's mind and makes you their preferred candidate. Can you use LinkedIn to do the same?

One other thing is that some of the people I have met while looking for work have been the most interesting and insightful people and are certainly the type that I want to add to my list of contacts. I usually wait until I hear how the decision went and then send a request.

Am I being over cautious?
Am I shooting myself in the foot while all the other candidates are jumping in as fast as possible to make a good impression and I seem uninterested?

Or, am I doing the right, ethical thing?

Slideshow: A Practical Example to Using SABSA Extended Security in Depth Strategy

A Practical Example to Using SABSA Extended Security-in-Depth Strategy from Allen Baranov

Following on from my last post, this is a practical way of using the extensions I proposed for the Security in Depth part of SABSA.

It gives an example of creating a Firewall Standard using the extensions.

I found this to be easier to do with a presentation than explaining it on the Blog so there you go.

Please let me know if you have any comments on this process.

Also, note that I am still looking for a job preferably in Information Security Management, Compliance or Information Security Architecture. Have a look at my linkedin profile for more information - http://au.linkedin.com/in/allenbaranov

- Allen Baranov

A more positive and comprehensive SABSA Strength-in-depth Strategy

[Extending SABSA's Strength-in-Depth Strategic Controls]

SABSA is brilliant. In one short week, I had my head expanded to exploding point. I highly recommend it to any Security person who is looking to understand more how what they do impacts on a Business. 

What is very interesting is that Business people understand risks. That is what they do. They understand governance and they also understand (to complete the GRC triad) compliance. They may just not understand  IT specific Risks, controls, etc. Usually IT is structured that the Business talks to the CIO or some form of "Business Specialists" who represent IT to the Business. But, the CIO usually doesn't understand risks and the Specialists almost certainly don't. IT is not keen to wheel out the Security guys to talk to Business but SABSA is a useful tool to help all three parties - IT, Business and Security to talk positively and come up with real solutions.

One of the really clever features of SABSA is that when it comes to "Attributes" which are basically "things the company would want to have" - they are all positive. "We want to put these controls in place so we don't fail our Audit" is not as good as "If we implement these controls, we will be totally compliant". "If we don't fix the authentication issues, someone may hack us and change stuff" is not as good as "If we fix the authentication issues, we will have a higher level of comfort around the integrity of our financials." A Business person hearing that will hear "blahblahblah..comfort..integrity..financials" and will give you at least some time to explain the "blahblahblah". Brilliant. 

All fired up after the course, I was thinking about how to write Standards so that they would have a similar level of positivity in their descriptions. The first Standard I turned to was the Firewall Standard. I then looked at the SABSA Strategy-in-depth sheet and it was obviously a "Prevent" control. (Or Preventative, even.) But that is the default state of a Firewall and has the same effect as unplugging the cable from the Internet router. You are essentially preventing everything... this is very safe... but not very useful, obviously. So, we open rules for traffic that is allowed. This is necessary and fits in with the whole SABSA features of "business driven" and "risk and opportunity based". So, for this to work - there should be a positive to each of the negatives for the Strength-in-depth controls. 

"Prevent" was easy - the opposite is "Allow". So, working from this - a Firewall Policy is a combination of negative and positive controls that allow good traffic flow and prevent bad traffic flow. Restating that - "We have a Firewall with a policy/rule-base/control-list that blocks bad traffic so as to allow good traffic to enable good business transactions". 

Spam-control - "We prevent spam at the border and allow good mail to flow inside our network to make management of mail more efficient, cost effective and keeping staff motivated."  

I chose to group these actions as "Enforcement". 

That was quite easy... what about "deter"? Well, deter is informing "users" of what not to do and what the consequences may be. The opposite is informing user what they can do and informing them of the benefits of connecting. My choice of word for this is "invite" and the group is "negotiate". This can cover more than just MOTDs and logon warnings. Once you add the positive aspect to it, it can cover Acceptable Use Policies and Terms and Conditions. 

The interesting thing is that once you define "Negotiate" and "Enforce" and add in the positive aspects - they also flow easier - once you negotiate that someone may use a certain system - you remove the enforcement that denies them access and allow them to access the system within the limits of what was negotiated. 

So, those are the first two controls in the strategy - the easier two. The others are "contain", "detect and notify", "evidence and track","recover and restore" and "assure". My feeling is that "assure" is the odd one out. It is almost a meta function of this process. In programming terms we would have an API that feeds what we are doing into the next level for assurance. "The Firewall is blocking all bad traffic and allowing all good traffic" is assurance. So for each control we need to consider "assurance" but I don't believe it deserves a category all of its own. 

Moving along, I have had some difficulty in working out the positive aspects of the other controls. "Contain" is like an adhoc post-breach denial of a certain type of traffic or user or system. This could fall into "Enforcement" as "Post Breach Enforcement" which would have the positive being "allow known good traffic or system or user to operate without being influenced by known bad traffic which is contained (denied access to the known good systems)." 

I have grouped "Detect and notify" into "Activity Monitoring". If it is a good transaction then it should be detected and the service can be performed on it. If it is a bad transaction then it should be detected as such and the correct person should be notified in a predefined timespan. 

"Evidence and Track" can be done for all traffic. This is "Traffic monitoring". Bad traffic should be recorded and analysed. Good traffic should be baselined and services improved accordingly. I have called this "Traffic Monitoring" but I think it can be used for all types of actions. However, I believe it to be more general than Activity Monitoring which looks at a specific event in depth, whereas this applied to a more broad stream of activities. "Activity Monitoring" would notify of a user locked out of their account. "Traffic monitoring" would notify of a number of strange attempts to guess passwords across the organisation. 

"Recover and Restore" is very important but I haven't applied a positive aspect or generalisation to it just yet. I think it deserves more thought. 

So, in summary - here is my list with the original SABSA strategic controls - my generalised groups and the additional positive strategic controls. 

This is still a work in progress so any comments or creative criticism would be appreciated. 

I haven't used this model in any practical applications but I am keen to as soon as possible. 

If you know nothing else about Information Security... know this!

[The best advice you can get (today anyhow)]

Information Security, like any other profession or specialisation has a lot of technical confusing terms and jargon. It has tools that only experts can use and statistics that only the same experts can read. It creates a brotherhood (and sisterhood) of professionals and this is fine.

But, also like other professions, Information Security has its borders of knowledge and its dark scary patches. "Thar be dragons!" Or pirates, or the end of the earth. Or (back to Security) APT. Or super skilled haxors with l33t everything. The guys that can escape jails and sandboxes. They can string single characters together to create small but dangerous stack attacks where there is no stack. And evade DEP and take over phones that don't allow even good programs to do naughty things.

These are the stories that Information Security professionals tell each other. These are the stories they tell their kids over camp fires and only at night and slowly and carefully. Each. Word. Leading. To. The. Next . Scary. Word.

But the reality is quite different. Most doctors that I know, even GPs and only the good ones, have specialities and other interests (not Golf..) because, although they have been through many years of medical school, most of their patients are either suffering from a cold or flu and require either pain killers and cough syrup or antibiotics. The more interesting patients may suffer from allergies to penicillin but that is where it ends.

So it is with Information Security. While we worry about super-great hackers - the two biggest highest profile breaches of recent times have been via a Firewall backdoor in the Playstation network that relied on people not digging in their Playstations' code. And a trojan email sent to some non-technical staff at RSA Security that led to them recalling their entire product range and their devices used to break into some US government departments.

Verizon comes out each year with a report on major breaches across the world. Every year it tells the same story - they are opportunistic and not targeted and they are generally (68% in the 2013 report) easy.

So, if all Information Security is, is a lot of flu... what is the Vitamin C equivalent?

Websense is a company that specialise in border control systems. They are the guys you swear at when you can't browse Facebook at work. They also block a lot of nasty sites and can block secret documents leaving an organisation. They have a lot of systems out there keeping people browsing what they are allowed to. A lot. They gather a lot of information too. Like, what version of Java people are running. They published this pie chart recently:

This is the spread of different Java versions that are used around the world, mostly in organisations but also by home users (and office staff who take their PCs home). The interesting thing about this pie chart is that if you are running anything but the version coloured dark blue at the top right or the thin red line next to it - you are at risk of downloading malware automatically. Let me rephrase that in my campfire voice - if you are not in the 5% of people running the latest version of Java in your browser, you can get infected by any number of types of malicious software (most that are out to steal your money or files) AUTOMATICALLY (fire crackles). You don't have to do anything to get infected, the website does it for you. More than that, your antivirus won't know about this "transaction" until it is too late. 5% of people in the world are safe from this. Simply because they are running the latest version of Java (which is free to upgrade.) That right there is your vitamin C. Patching Java (which 95% of people don't) will protect you from the flu. It won't protect you from interesting attacks but those are less likely to find you.

Do online attackers actually use Java? Yes, they all do, from guys looking to steal money, game credits and information to large Government agencies to groups like Anonymous and Lulzsec. Why? Because its easy to attack and works against 95% of all browsers. Why wouldn't they use Java exploits?

Advice? Patch Java. And flash too. And Microsoft software. Then sleep happy.

And go camping.