I felt a kind of relief when I read Richard Bejtlich's blog
where he said that security professionals should "routinely work both
offensive and defensive operations". In my interview with an
intelligence agency in the past, one of the interviewers asked me why I
wanted to work there. "I don't know", was my reply. But out of every
employer in the career fair I attended, I explained that theirs was the
only organization I bothered to write a (lengthy) cover letter for.
Although I did not understand my exact attraction to that organization, I
knew and wrote about one strategic advantage that no other organization
could provide: the opportunity to cover multiple roles and have an
understanding of the full spectrum of cyber security.
I
got a verbal offer to work there pending security clearance, which I of
course had to fail - perhaps because I had a foreign partner at the
time. So unfortunately (or fortunately) I am left in the private sector,
which leaves me with no choice other than to job hop around multiple
organizations in the future to fulfill my want to work in different
roles because most companies do not offer that many roles. And employers
do not like job hoppers, especially not the kind who switches companies
every 1-3 years continuously. But think about it. All other things
equal and assuming both are not slackers, would you think more competent
in advising your security the person who, for example, worked in
penetration testing for 10 years, or the person who covered 10 different
roles in 10 years? Personally, I would trust the latter.
In
my current position in which I've been in for less than half a year, I
already understand most of how the company's product provides security
for their customers - enough so to already begin to advise our systems
engineers who have years of experience on certain aspects of how the
security logic of the product worked. I would be staying in this company
for at least 1 year. And to be honest, I believe that even if I did
nothing else until the end of 1 year, I would already have delivered
enough value to the company due to some of my work. This is not to
boast, but simply an observation I make that an employee does not need
to stay in an organization for years to start delivering value. For
every job hop that I make, I would make sure that I first gave more than
I took from the organization.
The kinds of positions I am interested in are:
Security Analyst - the kind working in a Security Operations Center.
Security Researcher - researching about system internals, could be things like mobile phones or operating system internals
Advanced Penetration Tester -
I think it is important to make the "advanced" distinction because (and
I am not sure about this) I believe that many penetration testers do
very basic testing (e.g. Owasp Top 10).
Vulnerability Researcher
- the kind who tries to find a multitude of exploits in things. Similar
to penetration testing, the vulnerability researcher should not only
look at easily exploitable flaws such as buffer overflows.
Incident Response / Forensics
- understanding the trails that the attacker leaves behind is critical
in understanding how they could have been prevented or detected in the
first place.
Malware Researcher - I think a
Vulnerability Researcher is the coolest job possible in the realm of
cyber security - how many "security professionals" can write exploit
code? But if I had to choose a role which I am most interested in and
could do it for the rest of my life without job hopping, it would
probably be this (disclaimer: still job hopping)!
Come
to think of it, there are not that many positions I like, huh?
Incidentally, FireEye is one of the companies I plan to apply to in the
future. They also are one of the few organizations in the world which
have most of the positions I am interested in. Since Richard Bejtlich is
the Chief Security Strategist at FireEye, I suppose I would point the interviewing manager to Richard's blog if I get asked why I am moving around :)
Saturday, February 21, 2015
Wednesday, February 18, 2015
The dangers that lurk
Before I entered college, I was already fairly interested in cyber security. So when, many years ago, I happened to talk about that topic with someone who worked in an intelligence agency, I asked that person a question that I think every intelligence agency should ask themselves: how do you know the hardware you bought or the operating system you installed did not come infected with a backdoor?
That person replied that there basically wasn't much you could do about that. A strange answer, I thought - because if I were the head of an intelligence agency in charge of cyber warfare, that and rerouting non-secure downloads to malware servers would be my first two projects. Each of these two "vulnerabilities" could be prevented, of course - at a cost.
Rerouting non-secure downloads to malware servers
For a nation state, it would be fairly trivial to ensure that the executables they are downloading are always what they expect through forced checksums from secure verified identities - assuming they own both the server and client. For all other executables, they should either perform their own vulnerability assessments on those or not be using those anyway.
But normal people like us are unfortunately screwed. Of course, we could think that we would only download files from certified servers and verify the file checksum. That is somewhat true, but would not happen in reality. Think Java or Flash plugins, for example. These are distributed through HTTP and basically open to any MITM to be tampered with. Then think of tens or hundreds of other websites you download content from, which also use HTTP. Then think of the multitude of applications you use which might automatically search, download, and execute updates through insecure means. Not much you can do about that.
Should I stay in this field long enough to get sufficiently paranoid, one of the methods I would probably try to harden my system would be to create an application that runs through a one or more VPNs as an independent file verifier. When I download a file from the browser, for example, I would be downloading through my network and also downloading that same file through the VPN(s). After the downloads are complete, all those files would be compared to make sure they match. A little extreme maybe, but it is simply too easy for an attacker who is big enough to tamper with insecure downloads.
Backdoors in hardware or OS
As reported in the Kaspersky report (also linked above, see #10 in the report), intelligence agencies (probably the NSA) are and have already been hacking firmware for years. There is really not much that can be done here, especially on an individual level. But if I was a sufficiently determined intelligence agency with enough resources, I would force all firmware to be created in house. For operating systems, I would probably fork out an open source operating system and continue internal development from there. For example, internal developers could simply follow the changelog of that unix version and make the same changes - but through their own code. Security through obscurity perhaps, but with sufficient vulnerability testing I believe it is still a better choice than having to wonder whether there is a in-built backdoor in the OS.
Final comments: security through obscurity
I always feel funny when people laugh at the weakness of security through obscurity. Just like blacklisting and whitelisting in my previous post, security through obscurity is a horrible thing to completely rely on. But those people do not realize its potential. Let us take a very simple example of some kind of router and assume that the computers connected to it do not have any other way to communicate other than through that router. All communications with the computer to the router are always secure. Now suppose the NSA tries to hack this intelligence agency. They sell other infected firmware and operating systems to government contractors. They send out spear phishing emails to key personnel and those related to the key personnel. They give out or drop infected USBs. They use a whole bunch of zero days. Eventually, they will get in.
But what happens if both the router and select trusted applications were set to have their own networking protocol? Maybe, the applications on the OS all appended a "1" to their packets, and the router automatically dropped all packets without that "1". The NSA would -never- get in unless they knew that secret (well actually they can get in, but they can't get data out). Even in the case of infected firmware. Now of course something stupid people could say is their backdoor would analyze the packets being sent and understand that secret, but that in reality would never happen. So assuming that secret never leaks, the NSA would have to hack the computer/router through physical access or an insider. By itself, I would say using this simple technique could halve the NSA's chances of a successful attack. And there are literally hundreds or thousands of other significant game changing security through obscurity methods like these that could be used. If properly done, security through obscurity offers zero downside (in the worst case, it only does not work) with a lot of potential upside.
Note: even in an air gap environment, intelligence agencies would still need access to the internet. So they would presumably use one air-gapped computer and at least one other computer to access normal networks. Using such a theoretical security through obscurity protection would ensure that the risk of computer that is outside the air-gap environment is partially mitigated. Of course, there are other ways to breach an air gap and despite what recent reports claim, have been around for years.
That person replied that there basically wasn't much you could do about that. A strange answer, I thought - because if I were the head of an intelligence agency in charge of cyber warfare, that and rerouting non-secure downloads to malware servers would be my first two projects. Each of these two "vulnerabilities" could be prevented, of course - at a cost.
Rerouting non-secure downloads to malware servers
For a nation state, it would be fairly trivial to ensure that the executables they are downloading are always what they expect through forced checksums from secure verified identities - assuming they own both the server and client. For all other executables, they should either perform their own vulnerability assessments on those or not be using those anyway.
But normal people like us are unfortunately screwed. Of course, we could think that we would only download files from certified servers and verify the file checksum. That is somewhat true, but would not happen in reality. Think Java or Flash plugins, for example. These are distributed through HTTP and basically open to any MITM to be tampered with. Then think of tens or hundreds of other websites you download content from, which also use HTTP. Then think of the multitude of applications you use which might automatically search, download, and execute updates through insecure means. Not much you can do about that.
Should I stay in this field long enough to get sufficiently paranoid, one of the methods I would probably try to harden my system would be to create an application that runs through a one or more VPNs as an independent file verifier. When I download a file from the browser, for example, I would be downloading through my network and also downloading that same file through the VPN(s). After the downloads are complete, all those files would be compared to make sure they match. A little extreme maybe, but it is simply too easy for an attacker who is big enough to tamper with insecure downloads.
Backdoors in hardware or OS
As reported in the Kaspersky report (also linked above, see #10 in the report), intelligence agencies (probably the NSA) are and have already been hacking firmware for years. There is really not much that can be done here, especially on an individual level. But if I was a sufficiently determined intelligence agency with enough resources, I would force all firmware to be created in house. For operating systems, I would probably fork out an open source operating system and continue internal development from there. For example, internal developers could simply follow the changelog of that unix version and make the same changes - but through their own code. Security through obscurity perhaps, but with sufficient vulnerability testing I believe it is still a better choice than having to wonder whether there is a in-built backdoor in the OS.
Final comments: security through obscurity
I always feel funny when people laugh at the weakness of security through obscurity. Just like blacklisting and whitelisting in my previous post, security through obscurity is a horrible thing to completely rely on. But those people do not realize its potential. Let us take a very simple example of some kind of router and assume that the computers connected to it do not have any other way to communicate other than through that router. All communications with the computer to the router are always secure. Now suppose the NSA tries to hack this intelligence agency. They sell other infected firmware and operating systems to government contractors. They send out spear phishing emails to key personnel and those related to the key personnel. They give out or drop infected USBs. They use a whole bunch of zero days. Eventually, they will get in.
But what happens if both the router and select trusted applications were set to have their own networking protocol? Maybe, the applications on the OS all appended a "1" to their packets, and the router automatically dropped all packets without that "1". The NSA would -never- get in unless they knew that secret (well actually they can get in, but they can't get data out). Even in the case of infected firmware. Now of course something stupid people could say is their backdoor would analyze the packets being sent and understand that secret, but that in reality would never happen. So assuming that secret never leaks, the NSA would have to hack the computer/router through physical access or an insider. By itself, I would say using this simple technique could halve the NSA's chances of a successful attack. And there are literally hundreds or thousands of other significant game changing security through obscurity methods like these that could be used. If properly done, security through obscurity offers zero downside (in the worst case, it only does not work) with a lot of potential upside.
Note: even in an air gap environment, intelligence agencies would still need access to the internet. So they would presumably use one air-gapped computer and at least one other computer to access normal networks. Using such a theoretical security through obscurity protection would ensure that the risk of computer that is outside the air-gap environment is partially mitigated. Of course, there are other ways to breach an air gap and despite what recent reports claim, have been around for years.
Sunday, February 15, 2015
Blacklisting and Whitelisting
Whitelisting and blacklisting are two extremely common methods security folks use in attempt to identify threats. If they whitelist x, they are claiming that x is not dangerous and can be ignored - probably even if x exhibits malicious behavior. If they blacklist y, they are claiming that y is dangerous and special attention needs to be paid to it. There are inherent flaws in both approaches. That does not mean the method is broken; however, it simply means that as usual it must not be the single point of failure.
Blacklisting
Let us take the example of domain names (for example, www.phrack.org). If we blacklist this domain, it means that we think it is bad, and we could do something such as deny access to this domain or send a warning to your system administrator / security analyst. Phrack is a simple example, as we might think "I do not want someone to browse hacking related websites" or "I want to know who is interested in hacking so I can keep an eye out for that person". But this goes beyond hacking related websites. For example, we would also be interested in blocking and knowing attempts to connect to botnet command and control servers.
And therein lies the start of the problem. One of the buzzwords the security community tends to use as of late is threat intelligence/information, and the sharing of it. Look at the example of Facebook, which recently set up such an threat intelligence sharing platform. At its most basic, what this means is something like this: Twitter starts getting attacked by the Syrian Electronic Army (SEA), says their sea.sy domain is bad because it was used to attack them. And so since everyone trusts Twitter, they block sea.sy too. That is a good thing.. somewhat. But what happens when the attacker starts to use new domains? What happens if they hack a legitimate website to attack others? Nothing. As in, nothing is detected.
In sumamry, blacklisting is very effective against known threats but worthless against new ones. Another inherent flaw about blacklisting is size. A security program which is trying to fight fast flux, domain name generators, or polymorphic viruses simply cannot win over the long term. The blacklist would get bloated and still be useless against new threats. Proof? Symantec, one of the largest antivirus (which works based on blacklisting) players in the market, states that "Antivirus is dead". Blacklisting is a nice addition to have but a very bad thing to be reliant on.
Whitelisting
Since blacklisting identifies what is bad, whitelisting identifies what is good. When you set up your new database, for example, you may wish to allow connections to it only from your application server. That is great for security. But the problem with whitelisting is that you need much more than one item in your list. Suppose you want a whitelist which contains all executables which should be allowed to run on your computers. This is a huge task that only a security vendor would be willing to create. Even then, what happens when new legitimate applications get created? What happens when illegitimate applications get signed with legitimate code? Obviously, there are inherent problems with whitelisting too.
My thoughts
Let us get to the reason why I started this blog post. As I mentioned earlier, using blacklists is a horrible thing to rely on alone. But it does what it claims very effectively: if it is on the blacklist, it most likely is a threat. It should be blocked. A security vendor is not going to purposely put a good guy on the blacklist. A good guy is not going to pretend to be some guy on the blacklist. Someone who was on the blacklist but should not be there will eventually be removed from it (and if that person got on for whatever reason, that person should stay there for a while).
Whitelists, on the other hand, can get pretty dangerous. This is because of what it is meant to do: a blacklist says something like "tell me if there is a threat", but a whitelist says something like "do not show me anything if there is no threat". If there are no other indicators of compromise, something malicious which has been whitelisted somehow can wreak havoc in an organization undetected for a long time. Recently, I happened to be reviewing the logic behind some code in a security application which basically said "do not show me anything related to this if it is regarding communication from x". That works if you know x is something you can trust for a long time - which it was. However, the problem was that as I dove further into the logic, I realized that the application derived it was communicating with x through something an attacker could control. This means that if an attacker knew how the application was working, the attacker could hide entire communication streams from the defender. Very, very bad. Obviously, I am going to fix it.
Blacklisting
Let us take the example of domain names (for example, www.phrack.org). If we blacklist this domain, it means that we think it is bad, and we could do something such as deny access to this domain or send a warning to your system administrator / security analyst. Phrack is a simple example, as we might think "I do not want someone to browse hacking related websites" or "I want to know who is interested in hacking so I can keep an eye out for that person". But this goes beyond hacking related websites. For example, we would also be interested in blocking and knowing attempts to connect to botnet command and control servers.
And therein lies the start of the problem. One of the buzzwords the security community tends to use as of late is threat intelligence/information, and the sharing of it. Look at the example of Facebook, which recently set up such an threat intelligence sharing platform. At its most basic, what this means is something like this: Twitter starts getting attacked by the Syrian Electronic Army (SEA), says their sea.sy domain is bad because it was used to attack them. And so since everyone trusts Twitter, they block sea.sy too. That is a good thing.. somewhat. But what happens when the attacker starts to use new domains? What happens if they hack a legitimate website to attack others? Nothing. As in, nothing is detected.
In sumamry, blacklisting is very effective against known threats but worthless against new ones. Another inherent flaw about blacklisting is size. A security program which is trying to fight fast flux, domain name generators, or polymorphic viruses simply cannot win over the long term. The blacklist would get bloated and still be useless against new threats. Proof? Symantec, one of the largest antivirus (which works based on blacklisting) players in the market, states that "Antivirus is dead". Blacklisting is a nice addition to have but a very bad thing to be reliant on.
Whitelisting
Since blacklisting identifies what is bad, whitelisting identifies what is good. When you set up your new database, for example, you may wish to allow connections to it only from your application server. That is great for security. But the problem with whitelisting is that you need much more than one item in your list. Suppose you want a whitelist which contains all executables which should be allowed to run on your computers. This is a huge task that only a security vendor would be willing to create. Even then, what happens when new legitimate applications get created? What happens when illegitimate applications get signed with legitimate code? Obviously, there are inherent problems with whitelisting too.
My thoughts
Let us get to the reason why I started this blog post. As I mentioned earlier, using blacklists is a horrible thing to rely on alone. But it does what it claims very effectively: if it is on the blacklist, it most likely is a threat. It should be blocked. A security vendor is not going to purposely put a good guy on the blacklist. A good guy is not going to pretend to be some guy on the blacklist. Someone who was on the blacklist but should not be there will eventually be removed from it (and if that person got on for whatever reason, that person should stay there for a while).
Whitelists, on the other hand, can get pretty dangerous. This is because of what it is meant to do: a blacklist says something like "tell me if there is a threat", but a whitelist says something like "do not show me anything if there is no threat". If there are no other indicators of compromise, something malicious which has been whitelisted somehow can wreak havoc in an organization undetected for a long time. Recently, I happened to be reviewing the logic behind some code in a security application which basically said "do not show me anything related to this if it is regarding communication from x". That works if you know x is something you can trust for a long time - which it was. However, the problem was that as I dove further into the logic, I realized that the application derived it was communicating with x through something an attacker could control. This means that if an attacker knew how the application was working, the attacker could hide entire communication streams from the defender. Very, very bad. Obviously, I am going to fix it.
About me and this blog
It is always good to start off with an introduction, but I guess being a security-conscious person, I try to keep things private unless there is a specific reason to reveal it. So for example, I use this newly created google account registered to a prepaid phone number (but no burner phone!), writing to this blogspot using Tor with cookies always pre-cleared.
But at the very least, here are some basic details about myself which I think are pertinent to this blog:
And here are what I plan to do with this blog, and my reasons for doing so:
Disclaimer: Nothing I write here speaks for my employer. What I write here does not necessarily mean that it happened at my workplace.
P.S. I blame blogspot defaults for being so ugly! :)
But at the very least, here are some basic details about myself which I think are pertinent to this blog:
- I am in my mid-twenties
- I have a bachelor's degree, majoring in Computer Science
- I am working in the cyber security industry (private sector)
- I am in the process of creating a non-security related startup company
- I am interested in investing and have my own investments
And here are what I plan to do with this blog, and my reasons for doing so:
- Educate and provide commentary.
My primary focus for this blog is cyber security. That means that I will write about topics in cyber security that I happen to think about, in order to explain and comment about them. I used to read a lot of news related to this, but news is just news and I realize there are many things that the authors could have taught me from their articles but they did not.
But since I am already doing this, I would also sometimes write about what I have learnt from my startup attempt (no specific details). If someday my identity is revealed (actually pretty easy to figure out), I would also write a little about my investments. - Amalgation of my thoughts
This blog is not only for you, the reader, but also (mostly) for myself. Throughout my life I have realized that writing your thoughts - even if only about these topics - helps in self-understanding. - Possibly proof to future employers that I know at least something about cyber security
After all, everyone needs food on the table.
Disclaimer: Nothing I write here speaks for my employer. What I write here does not necessarily mean that it happened at my workplace.
P.S. I blame blogspot defaults for being so ugly! :)
Subscribe to:
Posts (Atom)