Security

From popdata
Jump to: navigation, search

Physical

Personally identifiable data (Type 1 data) will only be accessed in the RedZone. This area is protected in the following ways:

  • Enclosed area
  • Accessible only via a fob key for approved people. See Security/UBC Access Control
  • Reinforced walls, doors.
  • Alarm system
  • Video surveillance of all doors
  • Logs of all entries
  • Thin client computers (no hard drive, no media, nothing stored locally)

The servers and data storage will be located in a server room inside the RedZone. The server room:

  • is accessible to a restricted group of people.
  • is always alarmed
  • has video surveillance

The data itself will be kept on an encrypted filesystem. The physical disks could not be read without the encryption key.

Video Cameras

Four cameras:

Location type Address image-filename Notes
Main door Rasp-Pi pd-cam2 [10.99.99.191] *-1.jpg
Back door [disabled 180815] webcam Axis 207 camera1.conf pd-mgmt2sw Fa0/12 pd-cam1 [10.99.99.190] *-2.jpg 0040.8c88.c3fa
Server door webcam Axis 207 camera2.conf pd-cam3 [10.99.99.192] *-3.jpg
Server W. wall Rasp-pi pd-cam4 [10.99.99.193] pd-mgmt2sw Fa0/22 *-4.jpg b827.eb6c.2f0c
  • daemon /usr/bin/motion polls the webcams . It runs on Mackenzie in the redzone, and stores to /data/motion/data/<date> only when there is motion
  • raspberry Pi cameras are internally configured, and output directly to same folder via SMB
  • video and a single jpg are stored in /data/motion/<date>/<timestamp>-<camera>.avi or .jpg
    <date> format is one or both of YYYMMDD (for all 4 cameras inc. main door) && YYYY-MM-DD (only main door)
  • config files are in /etc/motion
  • webcams are directly accessed via: http://10.99.99.190/mjpg/video.mjpg (or just http://10.99.99.190/ for admin access)
  • testing is done via:
    • walk to the camera
    • go to /data/motion/<today>
    • make sure you can run X programs
    • mplayer 20130801103513-1.avi
  • TROUBLE 2018-08-14 found /var/log/motion/motion.log on Mackenzie filling /var at great rate with messages like
    netcam_read_next_header, streaming mode (1). unknown header '</BODY></HTML>!
    • Killed process "motion" started 2018-05-06 . Had open motion.log & both old webcams: 10.99.99.190 "pd-cam1" (back exit, working), 10.99.99.192 "pd-cam3" (server door)
    • The 2 raspberry-pi cameras (10.99.99.191 "pd-cam2" 10.99.99.193 "pd-cam4") save via SMB to /data/motion under 2 different daily folders: YYYYMMDD contains YYYYMMDD{-1,-4}{.avi,.avi.thumb}
    • 13:40 Fixed "/etc/init.d/motion restart". After dancing in front of the webcams, find under /data/motion/data/20180814/ 20180814133958-{2,3.{avi,jpg}. "-2" is back door; "-1" is server door.
    • 13:31 flood of error messages restarts. 15:55 lower log level to 3 "CRT" (Critical or worse). Now get every 10 seconds ""Network camera starting" immediately followed by "libjpeg decompression failure" apparently on camera1.conf
    • pd-cam4 Raspberry-pi from server storage wall pd-mgmt2sw Fa0/22 had setting "power inline shutdown 20 delay 30"; in ssh calls itself "pd-cam1". When connected to back door ethernet Fa0/12 it would light up, then fade after 10 seconds, probably due to confusion between its boot sequence briefly shutting down ethernet carrier.

Fob Logs

  • sent to security@popdata.bc.ca once a week on thursday
  • save the attachment to a name like: fob-20130801.rtf
  • transfer the file to cabot:/usr/local/src/fob
  • run: ./fob-access.pl -f fob-20130801.rtf -p [options: -s = show all; -p = show special (denied, unknown, server, after hours)
  • look for strange things, out of hours access, purple access, etc.
  • double check with out-of-hours people that they were really here.
  • tell Kaitlyn about other weird things
  • follow up with secure access about unrecognized individuals

Visitor log book

  • All visitors to "redzone" room are made to sign in and out, (and must be accompanied throughout their visit).
  • There is a separate log book for UBC Plant Operations staff. Even though they may have door fobx that let them enter at will, they must sign the separate log book.
    • The log books are reviewed by ??? and stored by ??? (probably Kaitlyn)

Network

Only special thin client RedZone computers will be able to access the Type 1 Data. This will be protected by:

  • Two factor authentication to log on (=> yubikey|)
  • No connection to the internet
  • Everything stored on the server, nothing stored locally
  • no access to local peripherals (no USB drives, CDROMs, hard disks)

Authentication

See Systems/Account_Management

What If's

Logging in:

Someone steals a SecurID token 
To log in you need the persons PIN number as well
Someone looks over a shoulder while logging in 
The person would get the PIN number for the user, but the SecurID code is valid only once.
Someone hacks the machine and reads the keyboard 
The person would get the PIN number for the user, but the SecurID code is valid only once.

Physical Security:

Someone forces open the door 
Alarm will sound, and Campus security will respond. In addition you cannot access the computers without a SecurID token and PIN.
Someone opens up a computer and boots from a hard drive they brought 
There is nothing on the local computer, and access to the servers still needs a SecurID token and PIN.
Someone steals a FOB to open the door 
They will trip the motion sensors and set off the alarm.
Someone steals a FOB and can disable the alarm 
They still can't access the servers without a SecurID token and PIN.
Someone tries to break through the wall 
The walls are reinforced with a thick wire mesh, however if this did succeed they would trip the alarm.
Someone follows someone in during the day when the area is not alarmed 
They would still have the problem of not being able to access the servers without a SecurID token and PIN
After successfully accessing the RedZone, and defeating the alarm, the person tries to access the server room 
The server room is accessible to only a very few users, and is always alarmed.
Someone however still accesses the server room 
They would still need to have a password to access the servers themselves.
Someone accesses the server room, and reboots the server to reset the password 
Upon reboot they could access the server, however all of the sensitive data is stored on an encrypted disk that can't be mounted except with the correct passphrase (known only to the data holder)
After accessing the server room, they decide to just take the disks 
The disk (at least those with sensitive information) are encrypted, they will not work on another system without the passphrase. It is not realistically possible to crack this (perhaps the NSA/CIA with enough time would have the resources to do this)

Network Security:

There is a security hole in the firewall software 
The PHLO network employs two firewalls, one for the yellow zone, and inside that, one for the RedZone. The firewalls are intentionally of different types. If there is a security hole in one of them, it is unlikely that there would also be a hole in the second.
Someone could tap the network connections 
All of the connections, switches, routers, and servers for the RedZone network are contained inside the physical RedZone. None of it is run over the UBC network.
Someone could hack a RedZone users PC (via an email or webpage) 
The RedZone users have two computers, one computer is in the YellowZone

Potential Weaknesses

No security is perfect. This is a list of potential ways a person could get access to the sensitive information:

  • All RedZone users must sign a confidentiality paper. While we have various protections in place to prevent the users from removing sensitive information from the RedZone, at some level we have to trust them.
    • They could for example bring a camera in to the RedZone and photograph information on their screen. Unless we want to search people every day when they leave to go home, there is little to be done to stop this
    • Users could also hide extra information in an extract that could later be retrieved with the complicity of the researcher