risk analysis for access control delegation and remote unlock in smart buildings
DESCRIPTION
Risk Analysis for Access Control Delegation and Remote Unlock in Smart Buildings. Nikita Borisov, Ragib Hasan, Sundeep Reddy. Agenda. Access Delegation Remote Unlock. Access delegation. Current Situation Andover: No concept of groups/roles LDAP servers has - PowerPoint PPT PresentationTRANSCRIPT
Risk Analysis for Access Control Delegation and
Remote Unlock in Smart Buildings
Nikita Borisov, Ragib Hasan, Sundeep Reddy
Agenda
Access Delegation Remote Unlock
Access delegation
Current SituationAndover:
No concept of groups/roles
LDAP servers has Access to the university system Has groups like csGrads, undergrads, faculty etc Has information on TA/RA appointments Can support constraints, rules etc.
Adding new people LDAP server has different objects information on students,
appointments, grad/undergrad etc. and is synchronized with the university system
At the start of the semester, a PHP script creates list of newly added students and related room permissions
The list is sent to TSG, and imported into Andover system
LDAP server Entries to be added Imported into
Andover
PHP Script creates entries
Personal Data Importer adds entries to Andover
University System
Adding access
TSG
ProfessorSpace Allocation
List
Student
1. Send Request to TSG for access to door
2. Looks up Space allocation or recall from memory
3. Find out if the person in charge of room agrees to allow access
4. Update Andover System
Problems
Large work load for TSG Only two people actually update the list Start-of-semester workload about 2 person-days Manual maintenance of request logs (email, text file)
Access policy, room ownership not precisely specified in the system; TSG has to rely on personal knowledge or space allocation list
Possibility of conflicts Possibility of errors Auditability
Problems (cont)
Inconsistencies between LDAP server and AndoverManual requests for access update Andover,
but not LDAP Inconsistent naming, ID, …
CleanupDifficult to know when to remove accessEntries in Andover don’t have groups and don’t
represent reason for access
Delegation
Define room owners Professor can have ownership of lab Access may be controlled by defining groups
Request for room access goes to room owner Room owner grants permission, access granted
immediately, the message goes to TSG and put in a queue
At the end of each day, TSG approves or rejects the access Automated conflict check (example: Number of people
with access to lab, exceeds capacity)
Benefits
Reduced load on TSG (time spent is less) Explicit ownership constraints (TSG doesn’t need
to have informal way of knowing who owns a door, don’t have to educate new employees, admins can go on vacation)
Reduced delay High delays in summer Smaller chance of mistakes
Confusing who owns door Confusing 2 doors net ids
Risks
Complexity of doors/multi door access Group maintenance overhead (if group
used) (what if people leave groups) Internet connectivity (of door access) can
cause compromise of door access, or subvert access control scheme
Lack of human check? Availability?
Issues
Will groups help? Large or small groups?(large groups such as
(faculties, grads, undergrads) or smaller groups such as (security research, database) ?)
Auditability Need for human check Expiration of access Visitor cards
Remote Unlock
Allowing people to unlock door locks via the Internet or smart phones
Currently done manually by TSG
Current Unlock Scheme
TSG
Locked out person
1. Go to TSG for opening door
2. Verify ID, verify person has access to door
3. Accompany person to door, use TSG’s card to open it, or open it remotely, monitor whether room state changes
Remote Unlock: Benefits Remote unlock reduces the load on TSG,
because any person who has locked himself out can go to a room anytime. Also, no third party authentication (like showing the personnel a drivers license, or other type of id) or personal verification is needed.
Easier recovery /reduced time Unlocking can be done at night or during breaks. Remote access -- A professor may provide
access to a grad student even if she is out of state.
Remote Unlock: Risks
Timing attacks When is the room unlocked? Immediately after
request? If unlock done over the Internet from some machine, anyone standing in front of the door can go in before the actual requestor arrives.
Timeouts?
No presence requirements: How do we ensure the person requesting the unlock is actually in front of the room? How do we make sure the person really entered?
Idea: can the door lock be used for other ways of authentication?
Remote Unlock: Risks
Authentication via Bluestem only? Is that sufficient/strong? What other methods can be used?
Human in the loop Do we need to verify such requests for abuse?
Main door Can we allow remote unlock of the main door?
Unauthorized persons If there is a problem, anyone without an I-card can be
able to enter.
Remote Unlock: Risks
Multi door access
Issues
PolicyWho can unlock door? The door owner, or
anyone with access to a doorShould we allow unlock at all doors? Are some
doors sensitive enough to have no remote unlock?