https://blog.knowbe4.com/cyber-criminals-use-domino-effect-chain-attacks-to-leverage-one-compromised-bank-to-infect-the-next?hs_amp=true&__twitter_impression=true
Showing posts with label Cybersecurity. Show all posts
Showing posts with label Cybersecurity. Show all posts
Monday, March 11, 2019
Friday, March 8, 2019
Computing - Server Side Cyber Threats
Now that I've already covered various topics on how the internet works, I want to revisit the notion of cybersecurity as 'defending a castle'.
Though really, it's probably more like 'defending a gated community'.
Picture your typical business as a gated community, with a front office (where mail is received and sorted), various different homes (where employees do their work), and a fulfillment center (surrounded by another wall) that receives and responds to client requests.
I am drastically oversimplifying this, since businesses vary greatly in how they configure their internal network - perhaps putting all the HR people in one walled off section, all the R&D people in another. Or having one building for receiving requests, and sending valid requests on to another building for fulfillment. That's not even getting into how a large company with multiple work locations would be configured, but I'm trying to keep it simple.
So then. Each house, the fulfillment center, and the front office all have their own 'Rosie' to receive and send messages. Rosie comes in all sorts of different makes and models, and if you know her model well you may even know of some 'tricks' that will get her to act in unexpected ways. You might send her a letter with keywords that make her start taking pictures of rooms in the house, or to open up a new window or door for a specific type of message traffic, or initiate some messages of her own.
The postal service delivers all mail to the front office in part because they don't actually have any addresses for anyone inside. It's of like how a large business might need someone to sort mail to a specific building or room, though if I'm going to maintain my previous analogies I'll just say that the robot maid in the front office assigns certain windows or doors to a specific home or building inside the community, and knows that any letters delivered to that location (i.e. door number 1470) goes to house number 42 in a process called NAT, or Network Address Translation. This developed in part because we were running out of IP addresses, and needed a way for computers to re-use some numbers. It's part of why if you check the IP address for your computer it's most likely to start with 192.168.1.X.
Anyways. What this means is that anyone outside the business has no real idea how to reach any of the homes inside the business unless they are directly responding to someone's messages. There's what's called an 'attack surface' of publicly facing connections - generally the front office and fulfillment center (since all the customers need to be able to reach the fulfillment center in order to make their requests.) Individual employees do offer up a target as well, but it's mostly because they're using their computer to access sites outside their place of work - gotta check those ESPN scores, you know? - and get responses in turn. (Okay, I'm halfway joking about ESPN. There are often legitimate work reasons to access outside websites... but you can communicate with everyone inside the gated community without going through the front office.)
All right, so what happens next? Well... it depends on a bit on what you're trying to do, tbh. This is also, btw, where I feel my inexperience shows the most... I'm trying to put into words my understanding of the process, but I may get it wrong. Feel free to comment with any corrections.
Let's start with one type of Denial-of-Service Attack, and it's close cousin a Distributed-Denial-of-Service attack. There you are, at the front office, when suddenly the mailman starts delivering bags and bags of mail. Much like the scene from Miracle on 33rd St, it overwhelms the front office and they wind up throwing away a lot of mail, including legitimate letters.
If it's a straight up DoS attack, you might notice that all the return addresses are the same, which makes it easy to tell Rosie to just throw them all away.
If it's a DDoS attack, the return addresses are generally different. Generally speaking, someone sent letters to a bunch of different robot maids, telling them to send letters to your address. It's called a botnet, and all the different return addresses indicate different robots sending letters as ordered.
Certain kinds of DDoS attacks will all be the same basic form, the color and/or size of a specific type of message (like an ICMP flood). There's still some things the front office can do to help filter it out, and they can also reach out to their nearest post office for help managing the flood of traffic, but it generally requires a bit more management than simply telling Rosie to throw out all the letters from x.x.x.x address.
This sort of attack will disrupt your business, but it's not really getting inside your community.
If you want to gain access to the businesses database there's probably two broad avenues of attack (I've never heard anyone put it like this, though, so maybe not). Basically you can do what we discussed earlier, where you manipulate the input at the company's website meant for use by a legitimate customer or you can try to take over the 'Rosie' that manages that particular building.
If you attack through the website, your message traffic looks superficially legitimate and will probably pass through the front office no problem. Then it gets forwarded for processing at the fulfillment center, and it's success depends on what sort of processes occur there. You're not really taking over any computers, you're just submitting a request in such a way that the fulfillment center will respond with information you're not supposed to have.
The other option (and the same sort of option you'd probably use to target the R&D section, or some other part of the business) is to try to reach a Rosie inside. Taking over the computer, or taking over 'a' computer and then pivoting to take over neighboring computers until you finally get the access you want.
This option can be used for all sorts of things, whether it's turning every Rosie into a member of a botnet, or getting Rosie to change information in the filing cabinet, or asking Rosie to take pictures of all the files and send them out to another location, and so on and so forth. You might even just tell Rosie to do nothing, to periodically check a particular window for messages.
But getting Rosie on your side... well, I'll get to that another day.
Though really, it's probably more like 'defending a gated community'.
Picture your typical business as a gated community, with a front office (where mail is received and sorted), various different homes (where employees do their work), and a fulfillment center (surrounded by another wall) that receives and responds to client requests.
I am drastically oversimplifying this, since businesses vary greatly in how they configure their internal network - perhaps putting all the HR people in one walled off section, all the R&D people in another. Or having one building for receiving requests, and sending valid requests on to another building for fulfillment. That's not even getting into how a large company with multiple work locations would be configured, but I'm trying to keep it simple.
So then. Each house, the fulfillment center, and the front office all have their own 'Rosie' to receive and send messages. Rosie comes in all sorts of different makes and models, and if you know her model well you may even know of some 'tricks' that will get her to act in unexpected ways. You might send her a letter with keywords that make her start taking pictures of rooms in the house, or to open up a new window or door for a specific type of message traffic, or initiate some messages of her own.
The postal service delivers all mail to the front office in part because they don't actually have any addresses for anyone inside. It's of like how a large business might need someone to sort mail to a specific building or room, though if I'm going to maintain my previous analogies I'll just say that the robot maid in the front office assigns certain windows or doors to a specific home or building inside the community, and knows that any letters delivered to that location (i.e. door number 1470) goes to house number 42 in a process called NAT, or Network Address Translation. This developed in part because we were running out of IP addresses, and needed a way for computers to re-use some numbers. It's part of why if you check the IP address for your computer it's most likely to start with 192.168.1.X.
Anyways. What this means is that anyone outside the business has no real idea how to reach any of the homes inside the business unless they are directly responding to someone's messages. There's what's called an 'attack surface' of publicly facing connections - generally the front office and fulfillment center (since all the customers need to be able to reach the fulfillment center in order to make their requests.) Individual employees do offer up a target as well, but it's mostly because they're using their computer to access sites outside their place of work - gotta check those ESPN scores, you know? - and get responses in turn. (Okay, I'm halfway joking about ESPN. There are often legitimate work reasons to access outside websites... but you can communicate with everyone inside the gated community without going through the front office.)
All right, so what happens next? Well... it depends on a bit on what you're trying to do, tbh. This is also, btw, where I feel my inexperience shows the most... I'm trying to put into words my understanding of the process, but I may get it wrong. Feel free to comment with any corrections.
Let's start with one type of Denial-of-Service Attack, and it's close cousin a Distributed-Denial-of-Service attack. There you are, at the front office, when suddenly the mailman starts delivering bags and bags of mail. Much like the scene from Miracle on 33rd St, it overwhelms the front office and they wind up throwing away a lot of mail, including legitimate letters.
If it's a straight up DoS attack, you might notice that all the return addresses are the same, which makes it easy to tell Rosie to just throw them all away.
If it's a DDoS attack, the return addresses are generally different. Generally speaking, someone sent letters to a bunch of different robot maids, telling them to send letters to your address. It's called a botnet, and all the different return addresses indicate different robots sending letters as ordered.
Certain kinds of DDoS attacks will all be the same basic form, the color and/or size of a specific type of message (like an ICMP flood). There's still some things the front office can do to help filter it out, and they can also reach out to their nearest post office for help managing the flood of traffic, but it generally requires a bit more management than simply telling Rosie to throw out all the letters from x.x.x.x address.
This sort of attack will disrupt your business, but it's not really getting inside your community.
If you want to gain access to the businesses database there's probably two broad avenues of attack (I've never heard anyone put it like this, though, so maybe not). Basically you can do what we discussed earlier, where you manipulate the input at the company's website meant for use by a legitimate customer or you can try to take over the 'Rosie' that manages that particular building.
If you attack through the website, your message traffic looks superficially legitimate and will probably pass through the front office no problem. Then it gets forwarded for processing at the fulfillment center, and it's success depends on what sort of processes occur there. You're not really taking over any computers, you're just submitting a request in such a way that the fulfillment center will respond with information you're not supposed to have.
The other option (and the same sort of option you'd probably use to target the R&D section, or some other part of the business) is to try to reach a Rosie inside. Taking over the computer, or taking over 'a' computer and then pivoting to take over neighboring computers until you finally get the access you want.
This option can be used for all sorts of things, whether it's turning every Rosie into a member of a botnet, or getting Rosie to change information in the filing cabinet, or asking Rosie to take pictures of all the files and send them out to another location, and so on and so forth. You might even just tell Rosie to do nothing, to periodically check a particular window for messages.
But getting Rosie on your side... well, I'll get to that another day.
Wednesday, February 27, 2019
Thought Provoking
When predicting enemy Courses of Action (COA) we were always supposed to look for what's most likely and most dangerous COAs. It helps to make sure you're ready in case the worst actually does happen.
I don't know nearly enough about Russia to say whether this prediction is true, but in terms of a 'most dangerous COA' it seems worth considering. Even if nothing of note happens, what could happen and do we have any countermeasures in place?
Check out @J_amesp’s Tweet: https://twitter.com/J_amesp/status/1094840317277282309?s=09
Wednesday, February 13, 2019
Cyber-Security Analogy, Cont.
Let's get back to the wizard in my analogy, and the challenges of mass production.
One of my classes covered material for the Certified Ethical Hacker (CEH) exam, which deals with penetration testing. For those who don't know, you get hired to try and hack into a business so that business can make themselves more secure. Being a penetration tester uses some of the exact same tools a hacker does, except it's done at the request of the target and comes with more report writing. Or so I hear.
We had some lab assignments to go with the academic material, and had a virtual lab with virtual machines that we tried hacking into. Metasploit is probably one of the best known tools for this, and it can be used by good and bad guys alike. We also dealt with stuff like Poison Ivy, and created some phishing e-mails and the like.
I brought up Metasploit because the software contains exploits for all sorts of vulnerabilities. You just have to figure out what type of system you're targeting select the exploit you want to use, and run it. Then bam! You're in, and can do all sorts of nasty things.
You don't have to know how to create the exploit yourself, you just run the program and let it do the work for you. (You probably want to learn a bit about what a defender would see when you do that, and how to minimize the risk, but that's a lot easier to teach then learning how to code an exploit yourself.)
Thus my original analogy, and comments on how mass producing guns changed things. You've got a 'wizard' that can create a program to exploit a vulnerability, a 'spell' if you will. They can either keep it to themselves or share it with everyone else, giving all potential attackers a 'spell' that will find hidden doors in the wall.
The spells themselves are not necessarily the problem, in that defenders use the exact same spells to test their defenses and brick up doors. The real problem is the wizard, and the system for distributing spells.
And that's about where I'll call this whole series of posts to a halt. I'm not entirely sure what the system is for distributing exploits, other than that you can see the results in Metasploit and other such programs. I've heard that organized crime has an entire system for this, so maybe understanding the Dark Net would help me come up with ideas on how to target that? Or should I just assume dissemination is a given, and ignore that entirely?
And as for the wizard... Hmmm. Targeting them gets into some of the same problems with attribution that I mentioned earlier. Though I suppose you could also try coming up with a program to turn them away from the dark side? I'm not sure how many would be interested in that, though. I don't really have a good profile for what the typical wizard is like, what motivates them to do what they do, etc.
Meh. Whatever. These are just some initial thoughts on the topic, based on what I've learned so far.
One of my classes covered material for the Certified Ethical Hacker (CEH) exam, which deals with penetration testing. For those who don't know, you get hired to try and hack into a business so that business can make themselves more secure. Being a penetration tester uses some of the exact same tools a hacker does, except it's done at the request of the target and comes with more report writing. Or so I hear.
We had some lab assignments to go with the academic material, and had a virtual lab with virtual machines that we tried hacking into. Metasploit is probably one of the best known tools for this, and it can be used by good and bad guys alike. We also dealt with stuff like Poison Ivy, and created some phishing e-mails and the like.
I brought up Metasploit because the software contains exploits for all sorts of vulnerabilities. You just have to figure out what type of system you're targeting select the exploit you want to use, and run it. Then bam! You're in, and can do all sorts of nasty things.
You don't have to know how to create the exploit yourself, you just run the program and let it do the work for you. (You probably want to learn a bit about what a defender would see when you do that, and how to minimize the risk, but that's a lot easier to teach then learning how to code an exploit yourself.)
Thus my original analogy, and comments on how mass producing guns changed things. You've got a 'wizard' that can create a program to exploit a vulnerability, a 'spell' if you will. They can either keep it to themselves or share it with everyone else, giving all potential attackers a 'spell' that will find hidden doors in the wall.
The spells themselves are not necessarily the problem, in that defenders use the exact same spells to test their defenses and brick up doors. The real problem is the wizard, and the system for distributing spells.
And that's about where I'll call this whole series of posts to a halt. I'm not entirely sure what the system is for distributing exploits, other than that you can see the results in Metasploit and other such programs. I've heard that organized crime has an entire system for this, so maybe understanding the Dark Net would help me come up with ideas on how to target that? Or should I just assume dissemination is a given, and ignore that entirely?
And as for the wizard... Hmmm. Targeting them gets into some of the same problems with attribution that I mentioned earlier. Though I suppose you could also try coming up with a program to turn them away from the dark side? I'm not sure how many would be interested in that, though. I don't really have a good profile for what the typical wizard is like, what motivates them to do what they do, etc.
Meh. Whatever. These are just some initial thoughts on the topic, based on what I've learned so far.
Cyber-Security Analogy, Cont.
If you want to change the threat environment, you can also consider ways of reducing the number of attackers. Right now it's really, really, really difficult to hold attackers accountable. It's not just that they can fake their id's, it's also that they may come from or pass through other nations on their way to attack your castle. And we don't necessarily have any sort of agreements with those nations that would allow us to enforce our laws on them.
While I do think we need better international cooperation to hold attackers accountable, there's another issue at work here. How do you identify someone as an attacker in the first place? How do you trace back their identifier to the original person?
Tackling that problem is something I have reservations about, in that it's great to focus on that if you want to catch bad guys, but it also is something that can be used to oppress or suppress good people. Consider what I'd said about wanting to explore the Dark Net, and wanting VPN and whatnot before doing so. My reasoning for all of that?
I want to understand the world on a holistic level... and the darker side is part of that. Can we truly understand economics, for example, without understanding the role shadow economics plays in it? I don't know... I don't think there's any equivalent to GDP for the underground economy. There might be a few studies that explore how money gets laundered and how much of it comes back into the legitimate economy, I dunno. Maybe the underground economy isn't large enough to really impact anything, maybe our economists can make sound decisions without ever considering that side of things... But how would we know if we never even consider the possibility?
It's a bit like how some biologists really love looking into how an ecology handles decay. Would there be horrible ecological consequences if we got rid of nasty critters like mosquitoes and flies? You don't know unless you look into it. (I think I read that we could get rid of mosquitoes with little to no consequences, which would be awesome if true and doable.)
The Dark Net seems like a good place to get a better understanding of the shadows in our world, but I have some serious trepidations about going there. It's like turning over a rock, or spelunking in a cave. I'm not sure what I'll find, I'm not sure what I would do with what I'd find, that sort of thing. But... I do know that before I go spelunking in such dark caverns I'd want to do my darndest to make sure nobody there could ever trace me back to my physical address. So I want a VPN service, might try to use Tor, that sort of thing. (I haven't tried too much to maintain privacy online so far, tbh. I know a lot of computer people who flat out refuse to use Facebook any more, but I still have a lot of friends and family there and haven't completely opted out yet.)
Bringing this back to cybersecurity - any attempt to make it easier to identify people online will also make it easier for abuse to happen. Like authoritarian governments tracking down dissidents, or online mobs doxxing people they don't like.
I have reservations about making it easier to identify people online, but I also know that attribution is especially important if we're dealing with a nation/state threat level and want to deter attacks.
How could Ukraine hold Russia accountable for the 2017 Petya attacks, and prevent any future such attacks from occurring, when Russia denies involvement and calls the accusations "unfounded blanket accusations".
Cyber-Security Analogy, Cont.
My previous analogy was... well, not an exact description of things. For example, a denial of service attack would be more like someone creating a bunch of clones to try to get through the gate. So many are trying to get through that it creates a really long line, and all other (legitimate) traffic gets fed up with the wait and leaves.
And you can also imagine that everyone trying to get through the gate has a unique number, identifying their origin. You can fake the number, of course, but you have to have a number of some sort. The clones might all share the same number (one attacker using one computer to generate a flood of attacks) or they might all have unique numbers (one attacker using a botnet under their control to generate attacks). The gate guards can potentially use that number to identify attackers and clear them out.
But...
That's not really why I created the analogy in the first place. I did it to create a different frame of reference, so I could look at the problem in a different way.
For example, much of cyber-security is focused on handling the daily attacks... figuring out ways of improving security at the gate, or blocking up the not-so-secret doors in the walls, or training people so that they don't throw ropes over the wall to let an attacker in.
Each of those fields has their cat-and-mouse, fast-paced development. Someone finds a new 'secret' door in the wall. If it's an enemy, they may keep it to themselves (a 'zero-day' attack that nobody knows about and can't defend against) or try to share it with everyone. If it's a defender, they may try blocking it up with bricks.
If/when both sides grow aware of it, there's a race between the defender to block it up and the attacker... where an enemy wizard creates a new spell to find the door, and spreads that information to all the people interested in getting into the castle. Does the door get blocked before an attacker gets through? Who knows?
All of that is necessary just to stay on top of things, but it doesn't really change the nature of the game.
Or perhaps it does, in the long run. Maybe. If the defenders can find and secure all the doors faster than new ones are found and exploited.
Maybe, someday, getting into the castle will become so difficult that most of the casual attacks drop off.
It'll probably be a long time before that happens, though.
So, what would change the nature of the game?
From my (very superficial, noobie) awareness, there are a couple of different ideas on how to do handle this.
For example, some people want to just rebuild the castle entirely, making sure that this time there are no secret doors or hidden passageways. (I think this gets into Trusted Computing, as well as the push for more secure software, holding software providers liable for vulnerabilities, and probably some other stuff I don't really know much about).
There are quite a few challenges to this goal, though. Imagine trying to rebuild a castle while you're still living in it and working out of it. Assuming you can make something entirely secure in the first place (there are arguments about that, and I don't have enough experience to have my own opinion on it. I mean, systems are complex and it's possible that we can't secure them entirely... but finding and fixing a security flaw like the infamous buffer overflow doesn't necessarily mean that doing so creates another vulnerability elsewhere, so in theory you should be able to secure it all? Maybe? Let me get back to this when I have a better idea of what I'm talking about.)
For anyone unaware - quite a bit of computer technology is concerned with "backwards compatibility". That way all your old programs and things will still work on the new system. It also, unfortunately, means that technology has all these 'kludges', or remnants of things that were necessary back when computers were built a certain way, but aren't now. Or rather, they're only needed now for backwards compatibility. And early computing was more trusting than we are now, so some security issues are intrinsic to decisions made way back when. If you could redesign everything from scratch, incorporating what we now know, things might possibly be different. But that would require a massive investment in time, energy, and money. There are, apparently, still numerous computers using really ancient software because businesses rely on that software and haven't been able to find an alternative on anything more recent. (Many tech people seem to have stories of someone finding an old system that nobody knows what it's used for any more, powering it off because something that old can't possibly be important any more, and discovering that doing so made it impossible for the business to function any more.)
Anyways. Rebuilding from scratch seems massively complicated, though there's some potential to the idea. Especially if you go with a gradual rollout, so businesses can adjust as their existing systems wear out and they have to buy new ones. (Sort of like the transition from IPV4 to IPV6, though you still have a lot of systems that requires the ability to use both.)
There's also the idea that we could secure the castle if we just held software vendors accountable for their software. That is, the hidden doors in your wall are not necessarily just from what you built. Or Microsoft, or Linux, or Apple. The operating system might have vulnerabilities, but any software you add to your computer can also come with vulnerabilities. So even if your operating system is secure, even if all known doorways are bricked up, if you downloaded and installed something (like an internet browser, or a game, or an application to manage your finances, or anything) that software might also create a hidden door in your castle walls.
And software companies, apparently, are well known for releasing products as quickly as they can... and fine-tuning them after they've gone public. Think of every new Windows operating system, or the time it took for Pokemon Go to smooth out all the bugs. The public acts as the final phase of testing for much of what gets released.
And, well... software is complicated. You can test, and test, and test, and probably won't find everything until you're doing it for real. Like when we changed our warehouse management system at my old company... I tested the heck out of it, but some things didn't become apparent until we were dealing with the number of users and orders we did on a daily basis. It's hard for a test environment to duplicate everything, and some problems are probably inevitable.
But that doesn't seem to be the real problem with this solution. After all, it shouldn't be too hard to have a reasonable standard of what is 'inevitable parts of producing a new product' and what is 'sheer laziness and the desire to make money quick'.
The real problem is that, in our current environment, nobody wants to add regulation that will unduly burden software vendors. Or maybe we don't need regulation, maybe we just need a really big lawsuit holding someone (Adobe, or Microsoft, or Google, or Apple, etc) accountable for the losses a business had when an attacker exploited a vulnerability in their product. Assuming you can, since I think we all tend to pro forma sign one of those Terms of Service that they'll probably use to deny liability for any such thing. Still, if software vendors have to pay a really large fee for any mistakes in their code, they'll probably start spending more money on development and testing for security in their product before releasing something new.
And if the case is big enough, and the vendor penalized enough, everyone else in the industry will take notice and start doing the same.
It may not stop attacks entirely, but it would at least make sure that there were fewer hidden doors to find. Of course, it would probably also slow down the software development process.
So those are just a few possible solutions. There's another way of looking at this, though.
I came up with the analogy I did because I wanted to think about what it meant, this mass distribution of the ability to hack into a target. The 'wizards' creating 'spells' that anyone could use.
Hmmm, before I focus on that I want to talk about something else.
Actually, given how long this is getting Imma gonna stop right here and start a new post.
And you can also imagine that everyone trying to get through the gate has a unique number, identifying their origin. You can fake the number, of course, but you have to have a number of some sort. The clones might all share the same number (one attacker using one computer to generate a flood of attacks) or they might all have unique numbers (one attacker using a botnet under their control to generate attacks). The gate guards can potentially use that number to identify attackers and clear them out.
But...
That's not really why I created the analogy in the first place. I did it to create a different frame of reference, so I could look at the problem in a different way.
For example, much of cyber-security is focused on handling the daily attacks... figuring out ways of improving security at the gate, or blocking up the not-so-secret doors in the walls, or training people so that they don't throw ropes over the wall to let an attacker in.
Each of those fields has their cat-and-mouse, fast-paced development. Someone finds a new 'secret' door in the wall. If it's an enemy, they may keep it to themselves (a 'zero-day' attack that nobody knows about and can't defend against) or try to share it with everyone. If it's a defender, they may try blocking it up with bricks.
If/when both sides grow aware of it, there's a race between the defender to block it up and the attacker... where an enemy wizard creates a new spell to find the door, and spreads that information to all the people interested in getting into the castle. Does the door get blocked before an attacker gets through? Who knows?
All of that is necessary just to stay on top of things, but it doesn't really change the nature of the game.
Or perhaps it does, in the long run. Maybe. If the defenders can find and secure all the doors faster than new ones are found and exploited.
Maybe, someday, getting into the castle will become so difficult that most of the casual attacks drop off.
It'll probably be a long time before that happens, though.
So, what would change the nature of the game?
From my (very superficial, noobie) awareness, there are a couple of different ideas on how to do handle this.
For example, some people want to just rebuild the castle entirely, making sure that this time there are no secret doors or hidden passageways. (I think this gets into Trusted Computing, as well as the push for more secure software, holding software providers liable for vulnerabilities, and probably some other stuff I don't really know much about).
There are quite a few challenges to this goal, though. Imagine trying to rebuild a castle while you're still living in it and working out of it. Assuming you can make something entirely secure in the first place (there are arguments about that, and I don't have enough experience to have my own opinion on it. I mean, systems are complex and it's possible that we can't secure them entirely... but finding and fixing a security flaw like the infamous buffer overflow doesn't necessarily mean that doing so creates another vulnerability elsewhere, so in theory you should be able to secure it all? Maybe? Let me get back to this when I have a better idea of what I'm talking about.)
For anyone unaware - quite a bit of computer technology is concerned with "backwards compatibility". That way all your old programs and things will still work on the new system. It also, unfortunately, means that technology has all these 'kludges', or remnants of things that were necessary back when computers were built a certain way, but aren't now. Or rather, they're only needed now for backwards compatibility. And early computing was more trusting than we are now, so some security issues are intrinsic to decisions made way back when. If you could redesign everything from scratch, incorporating what we now know, things might possibly be different. But that would require a massive investment in time, energy, and money. There are, apparently, still numerous computers using really ancient software because businesses rely on that software and haven't been able to find an alternative on anything more recent. (Many tech people seem to have stories of someone finding an old system that nobody knows what it's used for any more, powering it off because something that old can't possibly be important any more, and discovering that doing so made it impossible for the business to function any more.)
Anyways. Rebuilding from scratch seems massively complicated, though there's some potential to the idea. Especially if you go with a gradual rollout, so businesses can adjust as their existing systems wear out and they have to buy new ones. (Sort of like the transition from IPV4 to IPV6, though you still have a lot of systems that requires the ability to use both.)
There's also the idea that we could secure the castle if we just held software vendors accountable for their software. That is, the hidden doors in your wall are not necessarily just from what you built. Or Microsoft, or Linux, or Apple. The operating system might have vulnerabilities, but any software you add to your computer can also come with vulnerabilities. So even if your operating system is secure, even if all known doorways are bricked up, if you downloaded and installed something (like an internet browser, or a game, or an application to manage your finances, or anything) that software might also create a hidden door in your castle walls.
And software companies, apparently, are well known for releasing products as quickly as they can... and fine-tuning them after they've gone public. Think of every new Windows operating system, or the time it took for Pokemon Go to smooth out all the bugs. The public acts as the final phase of testing for much of what gets released.
And, well... software is complicated. You can test, and test, and test, and probably won't find everything until you're doing it for real. Like when we changed our warehouse management system at my old company... I tested the heck out of it, but some things didn't become apparent until we were dealing with the number of users and orders we did on a daily basis. It's hard for a test environment to duplicate everything, and some problems are probably inevitable.
But that doesn't seem to be the real problem with this solution. After all, it shouldn't be too hard to have a reasonable standard of what is 'inevitable parts of producing a new product' and what is 'sheer laziness and the desire to make money quick'.
The real problem is that, in our current environment, nobody wants to add regulation that will unduly burden software vendors. Or maybe we don't need regulation, maybe we just need a really big lawsuit holding someone (Adobe, or Microsoft, or Google, or Apple, etc) accountable for the losses a business had when an attacker exploited a vulnerability in their product. Assuming you can, since I think we all tend to pro forma sign one of those Terms of Service that they'll probably use to deny liability for any such thing. Still, if software vendors have to pay a really large fee for any mistakes in their code, they'll probably start spending more money on development and testing for security in their product before releasing something new.
And if the case is big enough, and the vendor penalized enough, everyone else in the industry will take notice and start doing the same.
It may not stop attacks entirely, but it would at least make sure that there were fewer hidden doors to find. Of course, it would probably also slow down the software development process.
So those are just a few possible solutions. There's another way of looking at this, though.
I came up with the analogy I did because I wanted to think about what it meant, this mass distribution of the ability to hack into a target. The 'wizards' creating 'spells' that anyone could use.
Hmmm, before I focus on that I want to talk about something else.
Actually, given how long this is getting Imma gonna stop right here and start a new post.
Tuesday, February 12, 2019
Cyber-Security, an Analogy
I applied to a few more places this morning, watched a video or two for Cybrary
(does free Cyber Security training. Though they offer a lot more if you
pay a monthly fee. The training and mentorship sounds amazing, but I
don't think I can commit to paying that fee until I have a reliable
source of income again. Which really rather sucks. Ah, the things I
would do if I had the resources right now! I think I'd get VPN, and try
exploring the Dark Net a bit. Buy a new laptop, I wonder if I could get a
hypervisor one and set up multiple VMs? One for Kali Linux, one for
Windows... I suppose I could try doing it with what I have, and maybe
I'm just making excuses for doing nothing, but my current setup is...
just not conducive to it.)
Anyways, I was remembering something from my undergrad years and figured I'd share it here:
I think I had a stint where I answered phones for our ROTC dept, or something, because I remember raiding the military library in the back and reading quite a bit of what I found. Most of it was fairly typical stuff. World War II stuff, like A Bridge Too Far. Or Vietnam, or the Civil War. One book I found particular fascinating discussed the evolution of military technology and it's impact on how we fought. I tried looking it up much later, and I think it was called From Crossbow to H-Bomb. I may be pulling info from various other things as well, but it's interesting how something like a stirrup or crossbow or gun can change the way we fight.
Guns, in particular, were interesting because up until then a fighter had to go through years of specialized training, and spend quite a bit of money. Learning to use a sword is not something you can do quickly, and if you want to talk about knights you also have to talk about the cost of their horses and armor.
Guns, on the other hand, are something you can train people to use within a couple of weeks to months worth of time. Not only that, but you can train women to use them, and they'll be just as effective as the next guy. They were, in some ways, an equalizer in that a peasant army could reasonably challenge the nobility on the battlefield with only minimal training. (Add in mass manufacturing and, well, the current military environment is very, very different.)
There was also some stuff about whether military technology favors defense or offense. For example, castles were built back when it favored defense. A well designed castle, so long as it had food and water, was nigh impenetrable. Sure, a besieging force might have sappers undermine the wall or find some other way through it, but it took time. Laying siege to a castle could take years, and it was too dangerous to just go around them since it often left an enemy to your rear.
But things changed and walls are pretty much useless now.
Just consider how easily we can send bombers over them, and I'm not even mentioning modern artillery. Heck, a tank can probably take out a wall in reasonably good time, though I'm a little unsure how long it would take to create a hole in a really thick castle wall.
Really, current technology favors offense and will probably continue to do so unless/until we learn how to make force fields. (And maybe that's a prediction people will laugh at in a couple of hundred years, too.)
Anyways, thinking of castles, military technology, and all that reminded me of cybersecurity.
If I were to make an analogy - current defenders are trying to protect their castle. I'm oversimplifying that, as within the castle walls are towers that have their own security and constantly communicate with each other, but let's keep it simple.
Defending the castle.
The current threat environment, on the other hand, goes something like this. Expert hackers have learned how to mass manufacture magical spells and guns. Someone might march up to the castle and cast a spell, suddenly creating multiple clones of themselves that launch attacks on the castle... preventing anyone from going in or out. (In other words, a botnet launching a denial-of-service attack).
When the path to the castle is clear, others approach the front gates and use a magical spell to make themselves look like one of the castle citizens. They pass through security and onward into the castle.
Still others wander around the walls of the castle, casting spells that allow them to find hidden doorways and secret passageways.
And then there are still more attackers, who have information on people within the castle and are trying to convince them to let down a rope.
That's not even including the disgruntled castle citizen that decides to let down a rope or throw open a hidden door of their own volition.
Some of the attackers are doing it for fun, others are doing it to make money, and still others represent enemy nations, but they all have access to magical spells.
The problem isn't just the multitude of ways they can attack, the problem is also that the ability to attack has become mass-produced, so that all these various attacks may be occurring simultaneously. Numerous times a day.
And that is the current threat environment.
Anyways, I was remembering something from my undergrad years and figured I'd share it here:
I think I had a stint where I answered phones for our ROTC dept, or something, because I remember raiding the military library in the back and reading quite a bit of what I found. Most of it was fairly typical stuff. World War II stuff, like A Bridge Too Far. Or Vietnam, or the Civil War. One book I found particular fascinating discussed the evolution of military technology and it's impact on how we fought. I tried looking it up much later, and I think it was called From Crossbow to H-Bomb. I may be pulling info from various other things as well, but it's interesting how something like a stirrup or crossbow or gun can change the way we fight.
Guns, in particular, were interesting because up until then a fighter had to go through years of specialized training, and spend quite a bit of money. Learning to use a sword is not something you can do quickly, and if you want to talk about knights you also have to talk about the cost of their horses and armor.
Guns, on the other hand, are something you can train people to use within a couple of weeks to months worth of time. Not only that, but you can train women to use them, and they'll be just as effective as the next guy. They were, in some ways, an equalizer in that a peasant army could reasonably challenge the nobility on the battlefield with only minimal training. (Add in mass manufacturing and, well, the current military environment is very, very different.)
There was also some stuff about whether military technology favors defense or offense. For example, castles were built back when it favored defense. A well designed castle, so long as it had food and water, was nigh impenetrable. Sure, a besieging force might have sappers undermine the wall or find some other way through it, but it took time. Laying siege to a castle could take years, and it was too dangerous to just go around them since it often left an enemy to your rear.
But things changed and walls are pretty much useless now.
Just consider how easily we can send bombers over them, and I'm not even mentioning modern artillery. Heck, a tank can probably take out a wall in reasonably good time, though I'm a little unsure how long it would take to create a hole in a really thick castle wall.
Really, current technology favors offense and will probably continue to do so unless/until we learn how to make force fields. (And maybe that's a prediction people will laugh at in a couple of hundred years, too.)
Anyways, thinking of castles, military technology, and all that reminded me of cybersecurity.
If I were to make an analogy - current defenders are trying to protect their castle. I'm oversimplifying that, as within the castle walls are towers that have their own security and constantly communicate with each other, but let's keep it simple.
Defending the castle.
The current threat environment, on the other hand, goes something like this. Expert hackers have learned how to mass manufacture magical spells and guns. Someone might march up to the castle and cast a spell, suddenly creating multiple clones of themselves that launch attacks on the castle... preventing anyone from going in or out. (In other words, a botnet launching a denial-of-service attack).
When the path to the castle is clear, others approach the front gates and use a magical spell to make themselves look like one of the castle citizens. They pass through security and onward into the castle.
Still others wander around the walls of the castle, casting spells that allow them to find hidden doorways and secret passageways.
And then there are still more attackers, who have information on people within the castle and are trying to convince them to let down a rope.
That's not even including the disgruntled castle citizen that decides to let down a rope or throw open a hidden door of their own volition.
Some of the attackers are doing it for fun, others are doing it to make money, and still others represent enemy nations, but they all have access to magical spells.
The problem isn't just the multitude of ways they can attack, the problem is also that the ability to attack has become mass-produced, so that all these various attacks may be occurring simultaneously. Numerous times a day.
And that is the current threat environment.
Tuesday, December 18, 2018
Musings
I suppose I ought to explain a little bit more about my previous post.
I sometimes think about Whitney's Houston song, One Moment in Time. It captures something I want, a driving force if you will... the urge to have that one moment in time, one moment "where I'm all that I thought I could be."
I suppose it's pretty much the top tier of Maslow's hierarchy of needs. Self-Actualization.
Computers...
Well. Putting this into words is harder than I thought.
When I learn something, I tend to get a feeling for the connections between things, holistically I guess. I don't really like rote memorization, but if I can sense the connections between things I'm pretty good at remembering how it all fits together. I sometimes use terms like 'see' or 'visualize', but it's more visceral than that. Sort of like building a mental map, or following a flow chart I guess.
When I learn something new, it's a bit like building a puzzle. I get a piece, I find it connects to another piece, and the more I immerse myself in the topic the more pieces I get, the more connections are formed, the more the pieces fall into place and the more complete the picture gets. I sometimes get formal training (MDMP, IPB, etc) and sometimes it's stuff I pick up on the job... mostly by jotting down anything unfamiliar and asking about it. Do that often enough, and soon you too can throw out an alphabet of acronyms - ECS, AMG, IPB, EJK, VBIED, etc.
All that is sort of like learning the basic rules of a game (like canasta). Training in the basics and whatnot. It starts off unfamiliar, but the more I immerse myself the more it all starts coming together.
I've always had an interest in national security issues, and cyber security is sort of uncharted territory there. A new dimension that we're just beginning to make sense of. We've got doctrines regarding land warfare, naval warfare, aerial warfare. We kind of know how they work, even though things change as technology changes (i.e. how fast you can maneuver, what sorts of countermeasures work against what, etc.)
But cyber security? We're all still figuring out what's even possible, much less how to counter it.
Right now... well, right now I'm at the very beginning of learning the field. Okay, sure. I've got a master's degree in computer science now. It reminds me of what they say about black belt training - i.e. the black belt just means you're ready to begin learning. It's nice to read articles and realize I can actually follow most of it. I can throw out terms like TCP, UDP, IP, IDS, SSH, FTP etc. and have a fairly good idea of what they mean.
But it's just the beginning. Give me five to ten years of experience and further training (if I can get my future place of employment to pay for some SANS courses that'd be hella awesome), and maybe I can talk knowledgeably about cyber warfare.
So no real regrets about the things I mentioned in my previous post. I know some of that is typical human behavior (i.e. we have a tendency to make stories about our lives and to a certain degree it's easy to be at peace with things when I feel life is going well. I had a phone interview that went well, have an in-person interview scheduled for January, and if things work out then life is good and I have no real complaints.)
And who knows, maybe in five-ten years I'll have a sense of where cyber warfare fits in with the rest of it.
I sometimes think about Whitney's Houston song, One Moment in Time. It captures something I want, a driving force if you will... the urge to have that one moment in time, one moment "where I'm all that I thought I could be."
I suppose it's pretty much the top tier of Maslow's hierarchy of needs. Self-Actualization.
Computers...
Well. Putting this into words is harder than I thought.
When I learn something, I tend to get a feeling for the connections between things, holistically I guess. I don't really like rote memorization, but if I can sense the connections between things I'm pretty good at remembering how it all fits together. I sometimes use terms like 'see' or 'visualize', but it's more visceral than that. Sort of like building a mental map, or following a flow chart I guess.
When I learn something new, it's a bit like building a puzzle. I get a piece, I find it connects to another piece, and the more I immerse myself in the topic the more pieces I get, the more connections are formed, the more the pieces fall into place and the more complete the picture gets. I sometimes get formal training (MDMP, IPB, etc) and sometimes it's stuff I pick up on the job... mostly by jotting down anything unfamiliar and asking about it. Do that often enough, and soon you too can throw out an alphabet of acronyms - ECS, AMG, IPB, EJK, VBIED, etc.
All that is sort of like learning the basic rules of a game (like canasta). Training in the basics and whatnot. It starts off unfamiliar, but the more I immerse myself the more it all starts coming together.
I've always had an interest in national security issues, and cyber security is sort of uncharted territory there. A new dimension that we're just beginning to make sense of. We've got doctrines regarding land warfare, naval warfare, aerial warfare. We kind of know how they work, even though things change as technology changes (i.e. how fast you can maneuver, what sorts of countermeasures work against what, etc.)
But cyber security? We're all still figuring out what's even possible, much less how to counter it.
Right now... well, right now I'm at the very beginning of learning the field. Okay, sure. I've got a master's degree in computer science now. It reminds me of what they say about black belt training - i.e. the black belt just means you're ready to begin learning. It's nice to read articles and realize I can actually follow most of it. I can throw out terms like TCP, UDP, IP, IDS, SSH, FTP etc. and have a fairly good idea of what they mean.
But it's just the beginning. Give me five to ten years of experience and further training (if I can get my future place of employment to pay for some SANS courses that'd be hella awesome), and maybe I can talk knowledgeably about cyber warfare.
So no real regrets about the things I mentioned in my previous post. I know some of that is typical human behavior (i.e. we have a tendency to make stories about our lives and to a certain degree it's easy to be at peace with things when I feel life is going well. I had a phone interview that went well, have an in-person interview scheduled for January, and if things work out then life is good and I have no real complaints.)
And who knows, maybe in five-ten years I'll have a sense of where cyber warfare fits in with the rest of it.
Monday, October 30, 2017
What I've Learned in School
The more I learn about computers, the more I realize how much there IS to learn. And the more I appreciate the hard work of those who've come before me. It must have taken thousands upon thousands of man hours every year to get where we are today.
This post is just typing out some of the things I've been piecing together, since I think it will help clarify some things for myself. So as not to get too bogged down in technical details, I'll just warn any readers that people can write books about each topic here, so this is definitely not an in-depth look at any of it.
The heart of computing is tied to simple electric switches. Think of a light switch to your living room - it's either on or off. Yes or no. 0 or 1. It's all...binary.
All computing comes down to turning millinos of tiny little switches either on or off. Which is why it's so freaking amazing that we have display screens, graphics, video games and more...all from a series of switches turning on and off.
Hardware (circuits, memory cards, etc) has to do with the physical ways we have of determining what switches are turned on and off. How your mouse or keyboard sends signals telling the computer to change some 0s and 1s on or off. Your computer has logic circuits, for example, which may look at two different locations and decide whether to turn a switch on or off based on what it sees. (i.e. if something is true you turn a switch on, and arbitrarily call it '1'. If it's false you turn the switch off, and arbitrarily call it '0'. If you only want something to occur if two items are true, you check to see if both are switched on...and only if both are on do you turn on another switch. x AND y turns on only if both x and y are on. x OR y turns on if either x or y is on. x XOR y turns on only if one or the other is on, but not both. Hence logic circuits can allow us to do complicated things based on whether switches are turned on or off...and can mimic our more formal logic.)
But 0's and 1's are really hard to work with, and it's too easy for us to make mistakes. So we came up with a number of things. We came up with some arbitrary sets of 0's and 1's to represent letters, for example (like ASCII and Unicode). And a way of telling the machine whether the 0s and 1s indicate numbers or letters.
We came up with something called Assembly Language, which allows us to tell a machine what to do without having to translate it all into 0s and 1s ourselves (the machine does it for us.) Assembly Language gets into the nitty gritty details of your computer, and how it does what it does. It means you have to tell it every little step of the way. Like giving extremely detailed instructions on how to drive your car to the store. You can't just say "drive down the street until you reach the third stop sign, then turn left." You have to tell it how to put a key into the ignition, how to put the car into reverse, how to step on the gas...all the tiny little details it takes to do this thing we call 'drive a car'.
This is interesting stuff, though, since I think that's where we get most of our security exploits. Oh, assembly language is also slow and tedious (though less slow than 0s and 1s), and we have even higher programming languages that are easier to use. We're learning some of them in my computer science courses. But figuring out how a piece of malware takes over a program and depends more on the mechanics going on at assembly level.
So then...
When you run a program, the central processing unit sets aside some places in memory for everything the program needs. You've got some identifying information, the code itself, initial variables, uninitialized variables that will be set during the running of the program, and a couple of interesting things called the heap and the stack. These things are stored in specific locations. Many programs require you to identify what sort of variable you are using (integer, character, etc) ahead of time so that the computer can reserve enough space to store that information when the program runs.
The heap and stack change size as needed while the program runs. The stack in particular makes things interesting, since it allows a program to do some pretty complicated things. See, every time you say "compare x to y, and if x is ____ do _____" it requires some complicated steps. First, you have to know where x is and where y is. Then you have to do the comparison.
So x and y get stored in registers, and there's special arithmetic logic unit that does the comparison and returns the result. The computer looks at that result...and often the result requires jumping to a new series of instructions. There's something called an instruction pointer that helps the computer keep track of where it is. It stores the memory location for the next instruction. If the program says to go to another set of instructions, the pointer will put in the new location for that instruction, and the program processes the instruction at that location.
I'm still learning a lot about how it all works, but the security flaw that sort of clicked in my head was a buffer overflow. If I understand what's going on correctly, what happens is that (unless someone is careful with their programming) any time you ask a user for input and the user provides something larger than what the computer expected, that information will fill the location set aside when the program was initialized and spill over into the next memory location. 'Overflow'. If you know where you are in the program, and what it's overflowing into, you can overwrite the values already at that location. If those values happen to be instructions for the program to run, you can give the program new instructions. You can basically tell the instruction pointer to jump to a totally different location where you've coded in malicious instructions (or just overwrite the existing instructions entirely, which will likely cause an error whenever that program is run...so it's kind of obvious. Better to make a small change pointing the code elsewhere, then return to the original program and run it like it's intended. Then the user won't notice anything particularly wrong.)
There's a lot more to it than that, of course, but it's nice to start making some connections out of all the stuff I'm learning.
This post is just typing out some of the things I've been piecing together, since I think it will help clarify some things for myself. So as not to get too bogged down in technical details, I'll just warn any readers that people can write books about each topic here, so this is definitely not an in-depth look at any of it.
The heart of computing is tied to simple electric switches. Think of a light switch to your living room - it's either on or off. Yes or no. 0 or 1. It's all...binary.
All computing comes down to turning millinos of tiny little switches either on or off. Which is why it's so freaking amazing that we have display screens, graphics, video games and more...all from a series of switches turning on and off.
Hardware (circuits, memory cards, etc) has to do with the physical ways we have of determining what switches are turned on and off. How your mouse or keyboard sends signals telling the computer to change some 0s and 1s on or off. Your computer has logic circuits, for example, which may look at two different locations and decide whether to turn a switch on or off based on what it sees. (i.e. if something is true you turn a switch on, and arbitrarily call it '1'. If it's false you turn the switch off, and arbitrarily call it '0'. If you only want something to occur if two items are true, you check to see if both are switched on...and only if both are on do you turn on another switch. x AND y turns on only if both x and y are on. x OR y turns on if either x or y is on. x XOR y turns on only if one or the other is on, but not both. Hence logic circuits can allow us to do complicated things based on whether switches are turned on or off...and can mimic our more formal logic.)
But 0's and 1's are really hard to work with, and it's too easy for us to make mistakes. So we came up with a number of things. We came up with some arbitrary sets of 0's and 1's to represent letters, for example (like ASCII and Unicode). And a way of telling the machine whether the 0s and 1s indicate numbers or letters.
We came up with something called Assembly Language, which allows us to tell a machine what to do without having to translate it all into 0s and 1s ourselves (the machine does it for us.) Assembly Language gets into the nitty gritty details of your computer, and how it does what it does. It means you have to tell it every little step of the way. Like giving extremely detailed instructions on how to drive your car to the store. You can't just say "drive down the street until you reach the third stop sign, then turn left." You have to tell it how to put a key into the ignition, how to put the car into reverse, how to step on the gas...all the tiny little details it takes to do this thing we call 'drive a car'.
This is interesting stuff, though, since I think that's where we get most of our security exploits. Oh, assembly language is also slow and tedious (though less slow than 0s and 1s), and we have even higher programming languages that are easier to use. We're learning some of them in my computer science courses. But figuring out how a piece of malware takes over a program and depends more on the mechanics going on at assembly level.
So then...
When you run a program, the central processing unit sets aside some places in memory for everything the program needs. You've got some identifying information, the code itself, initial variables, uninitialized variables that will be set during the running of the program, and a couple of interesting things called the heap and the stack. These things are stored in specific locations. Many programs require you to identify what sort of variable you are using (integer, character, etc) ahead of time so that the computer can reserve enough space to store that information when the program runs.
The heap and stack change size as needed while the program runs. The stack in particular makes things interesting, since it allows a program to do some pretty complicated things. See, every time you say "compare x to y, and if x is ____ do _____" it requires some complicated steps. First, you have to know where x is and where y is. Then you have to do the comparison.
So x and y get stored in registers, and there's special arithmetic logic unit that does the comparison and returns the result. The computer looks at that result...and often the result requires jumping to a new series of instructions. There's something called an instruction pointer that helps the computer keep track of where it is. It stores the memory location for the next instruction. If the program says to go to another set of instructions, the pointer will put in the new location for that instruction, and the program processes the instruction at that location.
I'm still learning a lot about how it all works, but the security flaw that sort of clicked in my head was a buffer overflow. If I understand what's going on correctly, what happens is that (unless someone is careful with their programming) any time you ask a user for input and the user provides something larger than what the computer expected, that information will fill the location set aside when the program was initialized and spill over into the next memory location. 'Overflow'. If you know where you are in the program, and what it's overflowing into, you can overwrite the values already at that location. If those values happen to be instructions for the program to run, you can give the program new instructions. You can basically tell the instruction pointer to jump to a totally different location where you've coded in malicious instructions (or just overwrite the existing instructions entirely, which will likely cause an error whenever that program is run...so it's kind of obvious. Better to make a small change pointing the code elsewhere, then return to the original program and run it like it's intended. Then the user won't notice anything particularly wrong.)
There's a lot more to it than that, of course, but it's nice to start making some connections out of all the stuff I'm learning.
Sunday, May 14, 2017
Update, Cybersecurity, Etc.
Finished with finals week. If I understand the professor's various grading scales correctly, I should get three As and an A-. Not bad, though I kind of hoped to do better on that A-. (Okay, as my brother says, I'm a bit of a grade snob. Sort of a "it's okay if others get less, but I should and can do better". Comes from always being in the 99th percentile on all those standardized tests. I can do better and should do better, unless there's mitigating circumstances like - for my first undergrad - wanting to explore who I was and have a life outside of homework.)
Anyways. Grades are good. I'm beginning to grasp just how big a field computer science is. I mean, you could specialize in so many different things. Making search and sort functions more efficient, improving natural language programming (such as used by Amazon's Alexa Voice Services), and more. I haven't even gone down the rabbit holes on topics like machine language programming, or quantum computing.
It's a big field, and unsurprisingly I'm drawn to cybersecurity the most. I plan to take a class this summer on incident reporting, and hope to get into one on malware as well. I'd held off on that because I'd hoped to take a business calculus class instead, but turns out this whole transfer student thing meant I had to jump through some hoops to show I already knew algebra. Ended up taking a placement exam, and am waiting for the math department to say if I'm good to go. So it's too late to take that course this summer, and (assuming I did well enough on the assessment) I'll try to take it next fall.
For one of my classes, I did a paper on cybersecurity. There's still a lot of things I don't know, of course, though I'm reading up on some things that will hopefully help. Still, I was struck by a comment from one my references...comparing cybersecurity to more traditional military offense/defense doctrine.
I delved into that a bit more to find what I was looking for, and I'll say it's a big and complicated subject most of which weren't relevant to my point. The important thing to me, at the time, was that certain technologies seem to favor defense or offense more. For example, castles and walls used to be almost impenetrable. That is, if you had enough food, water and defenders a castle could weather a siege...and sieges could last years. Castles were built when the technology of the time favored defense.
Now, of course, we have bombs and explosives so powerful that it's pointless to build a castle or wall. Or almost pointless, when fighting an enemy with modern conventional resources. In that sense, the technology favors offense more than defense. You can read up on what that means, and how it affects strategy, elsewhere.
As I was writing my paper, I was considering the castle analogy and decided that traditional offense/defense doesn't quite fit. Or rather, the strength of most of our computer networks comes from their ability to connect to each other, and that has implications for defense that make things different.
See, a physical castle could defend itself by closing the gates and raising the drawbridge...but a computer (or computer network) gains much of it's power through it's ability to connect. Defending a cyber castle is more like defending a castle while keeping the gates wide open. You can't close the gates and raise the drawbridge without hurting your ability to do what you need. You might add a few guards at the gates to try to check people's papers and make sure they're legitimate, but you want to keep those gates open.
It's actually a bit worse than that, even. A physical castle generally knew when it was besieged, since the enemy surrounded them (and wore uniforms, and all that). This is more like a castle trying to defend itself while keeping the gates wide open, and the besiegers aren't conveniently wearing a uniform. Some are trying to tunnel through the walls and find secret passengers, while others are stealing people's papers in order to get through the existing gates (and they're not all doing it for the same reasons, so it's not like you've got to defend against just one threat.) You've got sappers, spies, and saboteurs all working against you, as well as a possible besieging army (i.e DDOS attack) that forces you to close up the gates even when you don't want to.
Kind of changes how I think about defense, since you've really got two or three problems. One - securing the walls (i.e. finding any exploits that work through your existing defenses). Two - securing the necessary gates through proper authentication and identifying when someone is not behaving like they're supposed to be. And Three - making sure you can keep the gates open even if faced with a determined DDOS attack.
I have some other thoughts, but I'm a but too much of a nube to know what's possible, so I'll leave it at this.
Anyways. Grades are good. I'm beginning to grasp just how big a field computer science is. I mean, you could specialize in so many different things. Making search and sort functions more efficient, improving natural language programming (such as used by Amazon's Alexa Voice Services), and more. I haven't even gone down the rabbit holes on topics like machine language programming, or quantum computing.
It's a big field, and unsurprisingly I'm drawn to cybersecurity the most. I plan to take a class this summer on incident reporting, and hope to get into one on malware as well. I'd held off on that because I'd hoped to take a business calculus class instead, but turns out this whole transfer student thing meant I had to jump through some hoops to show I already knew algebra. Ended up taking a placement exam, and am waiting for the math department to say if I'm good to go. So it's too late to take that course this summer, and (assuming I did well enough on the assessment) I'll try to take it next fall.
For one of my classes, I did a paper on cybersecurity. There's still a lot of things I don't know, of course, though I'm reading up on some things that will hopefully help. Still, I was struck by a comment from one my references...comparing cybersecurity to more traditional military offense/defense doctrine.
I delved into that a bit more to find what I was looking for, and I'll say it's a big and complicated subject most of which weren't relevant to my point. The important thing to me, at the time, was that certain technologies seem to favor defense or offense more. For example, castles and walls used to be almost impenetrable. That is, if you had enough food, water and defenders a castle could weather a siege...and sieges could last years. Castles were built when the technology of the time favored defense.
Now, of course, we have bombs and explosives so powerful that it's pointless to build a castle or wall. Or almost pointless, when fighting an enemy with modern conventional resources. In that sense, the technology favors offense more than defense. You can read up on what that means, and how it affects strategy, elsewhere.
As I was writing my paper, I was considering the castle analogy and decided that traditional offense/defense doesn't quite fit. Or rather, the strength of most of our computer networks comes from their ability to connect to each other, and that has implications for defense that make things different.
See, a physical castle could defend itself by closing the gates and raising the drawbridge...but a computer (or computer network) gains much of it's power through it's ability to connect. Defending a cyber castle is more like defending a castle while keeping the gates wide open. You can't close the gates and raise the drawbridge without hurting your ability to do what you need. You might add a few guards at the gates to try to check people's papers and make sure they're legitimate, but you want to keep those gates open.
It's actually a bit worse than that, even. A physical castle generally knew when it was besieged, since the enemy surrounded them (and wore uniforms, and all that). This is more like a castle trying to defend itself while keeping the gates wide open, and the besiegers aren't conveniently wearing a uniform. Some are trying to tunnel through the walls and find secret passengers, while others are stealing people's papers in order to get through the existing gates (and they're not all doing it for the same reasons, so it's not like you've got to defend against just one threat.) You've got sappers, spies, and saboteurs all working against you, as well as a possible besieging army (i.e DDOS attack) that forces you to close up the gates even when you don't want to.
Kind of changes how I think about defense, since you've really got two or three problems. One - securing the walls (i.e. finding any exploits that work through your existing defenses). Two - securing the necessary gates through proper authentication and identifying when someone is not behaving like they're supposed to be. And Three - making sure you can keep the gates open even if faced with a determined DDOS attack.
I have some other thoughts, but I'm a but too much of a nube to know what's possible, so I'll leave it at this.
Subscribe to:
Posts (Atom)