designing self-contained plug-n-play security device

[Docster]

Hello - I'm looking for some help on designing a networked device both in terms of configuration and hardware.

The scenario is this - I am trying to design and build a self-contained, plug-and-lay (or more or less) security device that will contain a networked security device, power supply and wireless access point(s) and other networking equipment (switch or router which is to be determined here hopefully).

The unit should be able to work in any of the following "modes" using the same set of hardware.

Mode 1 - Standalone (meaning not connected to the internet at all, so not connected to any upstream devices).
In this mode, the onboard security device records data and stores it locally. The data will be accessible by connecting a laptop either via ethernet cable or via broadcasted Wi-Fi network. So the operator would get in wireless range, connect via browser or management software and manage the security device and download data etc.... DHCP in this mode would have to be via a device onboard the unit.

Mode 2 - Internet connected via ethernet cable (so requires onboard ethernet ports)
In this mode, the onboard security device records data and stores it locally, but the data is available either locally (as in Mode 1) or remotely over the internet. It would connect via net cable to a upstream router.

Mode 3 - Internet connected via Wi-Fi (so requires onboard ethernet ports)
In this mode, the onboard security device records data and stores it locally, but the data is available either locally (as in Mode 1) or remotely over the internet. It would connect via wireless bridge to an upstream router.

I'm thinking that this could be done via VLAN's. So create a VLAN that contains the security device and an access point to connect to for data download and management. That VLAN would have a DHCP server to assign an IP from maybe a more obscure private subnet. Then create another VLAN in which there would be an available ethernet port and another access point which would bridge to an upstream router/AP. This VLAN would not have a DHCP server so that the DHCP would be done via the upstream router.

So the questions I have are something like this
- Would VLAN's work in this scenario?
- would I need a router or could I do this just with a managed switch?
- Would I need 2 access points or is there maybe a device out there that can act as both an AP and a wireless bridge concurrently?
- Is there any conflicts or issues with DHCP set up like this? I.e. - one VLAN having a DHCP server and the other one that connects to upstream internet not have DHCP.
- any double nat issues created?

I hope this is clear but please let me know if any clarifications are required.

Thanks in advance.

[deanwebb]

Hello there, I'm ready to help with security concerns.

First and foremost, let there be no hard-coded usernames or passwords among your devices, lest they be smitten with ten thousand plagues! Seriously, that's a major no-no. Just want to get that off my chest.

Second, is the device running a full OS, a compact OS, or a minimal OS? This has implications for things like error-handling, random number generators necessary for encryption, and general resiliency. In your use cases, more functionality means more flexibility in each use case and error-handling success instead of buffer overflow when unexpected conditions arise.

Getting closer to your use cases, I consider it to be a best practice to have security devices in their own VLAN. You will potentially have customers that still have flat, unsegmented networks, so they will find a requirement for a separate VLAN to be not practical. Same for customers that are looking to use your device in a smaller office, with a limited IP range and typically zero local tech support.

For the first use case, that manual checking is labor-intensive. It also leaves itself open to an attacker using a default password set to connect and do improper things. With it being unconnected, there is no alerting on a breach event or even a successful logon event, and as such would not be acceptable in a military or government or regulated industrial environment. Home users would probably be OK with it. You also have issues if there is an exposed factory reset button. Does hitting the reset button wipe all data? If yes, it's an exploit for an attacker wishing to cover evidence recorded on the monitor. If no, then an attacker potentially has access to the data after resetting the password on the device. If resetting the device is limited to persons with a legit console connection and that the device does not collect data or allow access to data unless the password is changed from a default credential or a reset credential, then you may have something there. If built-in MFA controls the reset procedure, you're even better off. Overall, I'm not a fan of this use case, but it may be all that's possible for some remote or home environments.

Second use case: DHCP is typically fine for this. You will want native encryption in communications with the server. I'm assuming the connection to the Internet is a connection to a cloud-based server. If so, you will want a private encryption function built into the application that uses strong, non-PKI methods. Why not PKI? Because PKI is vulnerable to quantum-based attacks. They are on their way, so if you use non-PKI-based encryption, you are in a better place. Be sure to NOT roll your own, but to use legitimate, established encryption protocols. It's expected that quantum attacks will tear into PKI encryption in a matter of seconds, while they only halve the time for cracking established symmetric encryption methods. So symmetric encryption methods that would take longer than the heat death of the universe to unravel now will be unraveled with quantum attacks some time after the electron shells of all atoms in the universe have collapsed, so that's "good enough" in my book.

If data is available locally in the second use case, you have the security concerns from the standalone case to consider.

For the 3rd case, the wireless one, you're looking at your onboard wifi needing to be compatible with current standards as well as older ones, for customers still using legacy gear.

In both the networked cases, a simple ethernet card/wifi card is needed, no requirement for onboard switching, routing or wireless AP. Those are needed if and only if the device is also supposed to act as a point of connectivity for other devices.

You will want the devices to be configurable either with DHCP or a statically-assigned IP address. If the devices also have an IPv6 stack, then they can support the default addressing standards with that protocol pretty easily.

These are all endpoint devices, so they are a terminus in the network communication - they should just connect and all the networking devices they connect to will do the rest.

[Docster]

Thanks so much for the reply - I do appreciate it.

I think maybe I wasn't clear with what the device is. It is actually a security camera and the unit I'm building is a surveillance unit.

You were probably assuming it was a network or hardware security device.

Could you please take another run at this knowing now that it is a self-contained surveillance device?

Hello there, I'm ready to help with security concerns.

First and foremost, let there be no hard-coded usernames or passwords among your devices, lest they be smitten with ten thousand plagues! Seriously, that's a major no-no. Just want to get that off my chest.

Second, is the device running a full OS, a compact OS, or a minimal OS? This has implications for things like error-handling, random number generators necessary for encryption, and general resiliency. In your use cases, more functionality means more flexibility in each use case and error-handling success instead of buffer overflow when unexpected conditions arise.

Getting closer to your use cases, I consider it to be a best practice to have security devices in their own VLAN. You will potentially have customers that still have flat, unsegmented networks, so they will find a requirement for a separate VLAN to be not practical. Same for customers that are looking to use your device in a smaller office, with a limited IP range and typically zero local tech support.

For the first use case, that manual checking is labor-intensive. It also leaves itself open to an attacker using a default password set to connect and do improper things. With it being unconnected, there is no alerting on a breach event or even a successful logon event, and as such would not be acceptable in a military or government or regulated industrial environment. Home users would probably be OK with it. You also have issues if there is an exposed factory reset button. Does hitting the reset button wipe all data? If yes, it's an exploit for an attacker wishing to cover evidence recorded on the monitor. If no, then an attacker potentially has access to the data after resetting the password on the device. If resetting the device is limited to persons with a legit console connection and that the device does not collect data or allow access to data unless the password is changed from a default credential or a reset credential, then you may have something there. If built-in MFA controls the reset procedure, you're even better off. Overall, I'm not a fan of this use case, but it may be all that's possible for some remote or home environments.

Second use case: DHCP is typically fine for this. You will want native encryption in communications with the server. I'm assuming the connection to the Internet is a connection to a cloud-based server. If so, you will want a private encryption function built into the application that uses strong, non-PKI methods. Why not PKI? Because PKI is vulnerable to quantum-based attacks. They are on their way, so if you use non-PKI-based encryption, you are in a better place. Be sure to NOT roll your own, but to use legitimate, established encryption protocols. It's expected that quantum attacks will tear into PKI encryption in a matter of seconds, while they only halve the time for cracking established symmetric encryption methods. So symmetric encryption methods that would take longer than the heat death of the universe to unravel now will be unraveled with quantum attacks some time after the electron shells of all atoms in the universe have collapsed, so that's "good enough" in my book.

If data is available locally in the second use case, you have the security concerns from the standalone case to consider.

For the 3rd case, the wireless one, you're looking at your onboard wifi needing to be compatible with current standards as well as older ones, for customers still using legacy gear.

In both the networked cases, a simple ethernet card/wifi card is needed, no requirement for onboard switching, routing or wireless AP. Those are needed if and only if the device is also supposed to act as a point of connectivity for other devices.

You will want the devices to be configurable either with DHCP or a statically-assigned IP address. If the devices also have an IPv6 stack, then they can support the default addressing standards with that protocol pretty easily.

These are all endpoint devices, so they are a terminus in the network communication - they should just connect and all the networking devices they connect to will do the rest.

[icecream-guy]

I was thinking that a Raspberry Pi would be a good platform for this, if you had some programming experience with Linux variants. The world is yours. setting up multiple interfaces, and loading Wireshark on the platform,  and with logging you could script a VPN connection to upload logs whenever there is a network connection to someplace in the cloud,

I see the biggest problem is connecting to networks where you are not wanted,  e,g. NAC where you get put into a quarantine VLAN. you may get a DHCP address, and monitor other devices on the same network, but that's about all.

[deanwebb]

I was in fact considering a security camera. I have to deal with those all the time in my work. They're set up to provide physical security, but themselves are vulnerable to cyberattacks.

So, what are your parameters as far as credentialed access and OS for the device?

[Docster]

Thanks for the reply.

I don't think I've explained what I'm after very well because sorry but this doesn't seem relevant.

I was thinking that a Raspberry Pi would be a good platform for this, if you had some programming experience with Linux variants. The world is yours. setting up multiple interfaces, and loading Wireshark on the platform,  and with logging you could script a VPN connection to upload logs whenever there is a network connection to someplace in the cloud,

I see the biggest problem is connecting to networks where you are not wanted,  e,g. NAC where you get put into a quarantine VLAN. you may get a DHCP address, and monitor other devices on the same network, but that's about all.

[deanwebb]

It is relevant in terms of how the device handles an error condition or, in this case, an enforcement condition - what it does if it expects a network to access, but is denied.

[Docster]

That's not a concern for this device.

It is relevant in terms of how the device handles an error condition or, in this case, an enforcement condition - what it does if it expects a network to access, but is denied.

[deanwebb]

That's not a concern for this device.

I'd be interested for more details on your device. I have had some discussions with the Building Security Consortium about the need to secure devices being used for physical security, environmental controls, and the like, as they're typically devices we only see as connecting, doing their job, and being monitored for functionality and not considering them as the endpoints that they are, with potential vulnerabilities and opportunities to act as pivot points in an attack or for the data to/from the devices to be intercepted and used either to further an attack or to be the objective of the attack.

[Docster]

The device is a standalone video surveillance unit to be used for construction sites and the like.

I don't have any concerns about the security of the device itself.

At this point I'm just looking for help on spec'ing the correct networking hardware I should have on board.

I don't have any se

That's not a concern for this device.

I'd be interested for more details on your device. I have had some discussions with the Building Security Consortium about the need to secure devices being used for physical security, environmental controls, and the like, as they're typically devices we only see as connecting, doing their job, and being monitored for functionality and not considering them as the endpoints that they are, with potential vulnerabilities and opportunities to act as pivot points in an attack or for the data to/from the devices to be intercepted and used either to further an attack or to be the objective of the attack.

[deanwebb]

If you're going to have a lot of distance to cover, I'd recommend a private 5G network instead of standard wireless.

[Docster]

That isn't the type of info I'm looking for. That isn't an option.

Thanks for your help.

If you're going to have a lot of distance to cover, I'd recommend a private 5G network instead of standard wireless.