Group Actions
Engagement
  • Author Author: spannerspencer
  • Date Created: Date Created
  • Views 2247 views
  • Likes 1 like
  • Comments 17 comments
Related
Recommended

Computer Security Day - How to Secure Your Devices

spannerspencer

image

It's November 30th, which means it's A) Just under one month until New Year's Eve, and B) It's World Computer Security Day (CSD)!

 

You can find out a little more about the origins of the day itself over here, and tell us about your best practices when it comes to securing your digital life.

 

Beyond Computer Security

This is a long-lived awareness campaign already, but it's changing as fast as the computers it's based around.

 

CSD is a concept that increases in magnitude somewhere like the element14 Community. Here, we're interested in lots of different types of computers, microprocessors, systems and platforms; and most all of them involve some manner of digital security measures. A campaign that originally looked at encouraging people to change one, or maybe two passwords now involves something of an epic security endeavour for engineers, makers and tech-heads who are into all the available prototyping platforms out there now.

 

So is it also time to change the password on your Raspberry Pi root? Should your Internet of Things devices get a new login? Are there any concerns around your connected Arduino projects?

 

Updating a Windows password is easy, but updating a headless single board computer or homemade connected thermostat or wi-fi operated light fitting is something else entirely. Even those of us who take an active interest in these things might struggle to keep up to speed on every item we've built into a maker project.

 

So I'd like to encourage those of you in the know to pick a platform or process of your choice, and write a blog detailing how to change or update its passwords, logins or security features.

 

Tag it with "Computer Security Day" (and put a link to it in the comments here, if you like) and we'll compile all your cyber security instructions into a cyber security bible that will help keep our corner of the internet just a little bit safer. If we can enough blog posts together on the subject of cyber security, we could potentially edit these into an e-book that'll become a valuable reference for all of us.

 

 

Don't forget! Now that you've secured your digital self, come and tell us how you can make yourself and others safe and sound in the physical world, in our brand new Safe and Sound Design Challenge.

 

You could win a nice, safe quadcopter with which to "enhance" your neighbour's security and privacy!

Top Comments

  • in reply to Jan Cumps

    Well, like I said in my post "With regards to the IoT ongoing issues, security should be thought of from the start.", in my opinion the manufacturers and folks that build devices for others should think of security from the start.

     

    From what I understand, the cameras that are part of the Mirai botnet are directly connected to the internet and utilize a website to interface with them for regular use (the whole in the cloud management). 

     

    I guess my original post wasn't detailed enough, the gateway I referred to there was a gateway and/or firewall on my local network, not the cloud providers config/control page. 

     

    Security should be baked in from the start, the continuing use of default passwords, hard coded passwords that can't be changed, backdoors left in for testing, etc are the fault of the manufacturers and the lackadaisical approach that a lot of them take towards security.  It is also the fault of the consumer for not changing the default passwords. 

     

    Any device can be compromised, it just depends on the level of effort required versus the perceived value of the compromised device.

     

    Think of security like the multiple layers of an onion, that is what I try to achieve in my setup and with devices that I fiddle with.  I wasn't trying to imply that security on the individual devices should be neglected, but you shouldn't rely on just that one device either.  Implement good firewall rules on your router, and ensure that your devices are configured in a sane and secure manner, but keep in mind the trade off between secure and usable. 

     

  • in reply to jgerred

    James, doesn't your rule ignore the responsibility of the IoT device itself to be secured, and put security care "in someone else's well secured device"?

    That may be good enough if you build for yourself only. But what if you publish the design, or make it for others?

    The cameras that were hacked in the latest DNS DoS are devices that are connected via a gateway to the internet.

  • Security is a trade off between being secure and being usable.  If you buy a new computer, take it home, dig a hole 60 feet deep, put the new computer (still in the box) in the bottom of the hole, and then fill the hole with concrete, you have a reasonable assurance that the computer is "secure", however it is not very usable.

     

    With regards to the IoT ongoing issues, security should be thought of from the start.  If you are building a device that is going to be directly connected to the internet then you should make sure that there is a way of securing it while still making it usable and keeping in mind that what is secure today might not be tomorrow.

     

    My rule (not iron clad!) for devices I build and fiddle with is that they are not directly connected to the internet and require a gateway of some sort to get to them.  This minimizes the exposure since you only secure one device and make that as secure as possible (again, keeping in mind that there are risks of having it connected to the net).  Additionally, any device that I am fiddling with usually has a hard wired connection of some sort so it has less of a footprint open for attack vectors.

  • in reply to COMPACT

    But in Australia they'll transmit on one of our Cell phone frequency ranges!!

    Well then you can listen to the jubble ...

     

    I highlighted this in earlier discussions ...

    Sometimes the security of the packet is not the problem, it's the mere presecence of a packet that comprimises the security.

     

    If a criminal wants to target people returning to cars, then he only needs to detect the prescence of data.

    Obviously the chances of identifying the car is reduced with the number of cars in the car park.

     

    In this example there is no comprimise of the data, just the fact it is there.

     

    Mark

  • in reply to mcb1

    But in Australia they'll transmit on one of our Cell phone frequency ranges!!