security assignment instructions example

IFSEC Insider is part of the Informa Markets Division of Informa PLC

• INFORMA PLC
• INVESTOR RELATIONS

IFSEC Insider is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

• Anticipate London
• Advertise With Us
• Video Surveillance
• Access Control
• Intruder Alarms
• Corporate Security
• Physical Security
• Borders & Infrastructure
• Guarding & security officers
• Cyber Security
• Smart Buildings
• Fire safety news
• Building safety
• Fire protection
• Fire prevention
• Fire extinguishers
• Critical national infrastructure
• Leisure & sport
• Residential
• Installer zone
• IFSEC Interviews
• Influencers hub
• Influencers in fire 2022
• Influencers in security 2022
• The IFSEC Insider Podcast
• IFSEC Insider Influencers in Security & Fire
• Critical Conversations
• IFSEC Directory
• CCTV Technologies Guide
• Control Rooms
• Video Analytics
• Thermal Cameras
• Video Surveillance Manufacturers
• Safe Cities
• Drone Security
• Perimeter Security
• Security Officer
• Fire Safety Manufacturers
• Residential Housing
• IFSEC London
• IFSEC London Exhibitors
• FIREX London
• FIREX Exhibitors
• IFSEC India
• IFSEC Philippines
• IFSEC Southeast Asia
• Security Companies
• Mergers & Acquisitions
• Hanwha Techwin
• Arecont Vision
• The Fire Industry Association (FIA)

IFSEC Insider

Author Bio ▼

Sign up to free email newsletters

• Enter your email address.. *
• Country/Region --- Please Select --- Afghanistan Albania Algeria American Samoa Andorra Angola Antigua and Barbuda Argentina Armenia Australia Austria Azerbaijan Bahamas Bahrain Bangladesh Barbados Belarus Belgium Belize Benin Bermuda Bhutan Bolivia Bosnia and Herzegovina Botswana Brazil Brunei Bulgaria Burkina Faso Burundi Cambodia Cameroon Canada Cape Verde Cayman Islands Central African Republic Chad Chile China Colombia Comoros Congo, Democratic Republic of the Congo, Republic of the Costa Rica Côte d'Ivoire Croatia Cuba Curaçao Cyprus Czech Republic Denmark Djibouti Dominica Dominican Republic East Timor Ecuador Egypt El Salvador Equatorial Guinea Eritrea Estonia Ethiopia Faroe Islands Fiji Finland France French Polynesia Gabon Gambia Georgia Germany Ghana Greece Greenland Grenada Guam Guatemala Guinea Guinea-Bissau Guyana Haiti Honduras Hungary Iceland India Indonesia Iran Iraq Ireland Israel Italy Jamaica Japan Jordan Kazakhstan Kenya Kiribati North Korea South Korea Kosovo Kuwait Kyrgyzstan Laos Latvia Lebanon Lesotho Liberia Libya Liechtenstein Lithuania Luxembourg Madagascar Malawi Malaysia Maldives Mali Malta Marshall Islands Mauritania Mauritius Mexico Micronesia Moldova Monaco Mongolia Montenegro Morocco Mozambique Myanmar Namibia Nauru Nepal Netherlands New Zealand Nicaragua Niger Nigeria North Macedonia Northern Mariana Islands Norway Oman Pakistan Palau Palestine, State of Panama Papua New Guinea Paraguay Peru Philippines Poland Portugal Puerto Rico Qatar Romania Russia Rwanda Saint Kitts and Nevis Saint Lucia Saint Vincent and the Grenadines Samoa San Marino Sao Tome and Principe Saudi Arabia Senegal Serbia Seychelles Sierra Leone Singapore Sint Maarten Slovakia Slovenia Solomon Islands Somalia South Africa Spain Sri Lanka Sudan Sudan, South Suriname Swaziland Sweden Switzerland Syria Tajikistan Tanzania Thailand Togo Tonga Trinidad and Tobago Tunisia Turkey Turkmenistan Tuvalu Uganda Ukraine United Arab Emirates United Kingdom United States Uruguay Uzbekistan Vanuatu Vatican City Venezuela Vietnam Virgin Islands, British Virgin Islands, U.S. Yemen Zambia Zimbabwe
• I have read, understood and consent to your Privacy Policy .

Transforming security: The role of secure IoT connectivity within fire and security applications

Whitepaper: enhancing security, resilience and efficiency across a range of industries, do your security officers use assignment instructions.

As the managing director of a security consultancy business, and having worked in the security sector for 20 years now, I’ve seen many changes within the industry.

With the relatively recent introduction of the Security Industry Authority’s Approved Contractor Scheme (ACS), a standard has at long last been set. That standard has been much needed in the security sector.

In particular, the ACS has highlighted the importance of processes and documents in your business. It has made this mandatory in some cases, for example when it comes to site assignment instructions.

I have long held the belief that site assignment instruction booklets are one of the most important documents a security officer has access to while on duty (if not the most important). During my time working with all sizes of security company, I have come across many variations of site assignment instructions. There have been the two-page documents scribbled all over as practices have altered, all the way up to vast tomes designed to impress clients rather than aid the officer.

The feedback I have received about assignment instructions when speaking to officers has surprised me. In some cases, such little importance is given to these documents that certain security officers don’t even know what they are, and why they should be used.

On the other hand, we have officers who are frustrated as their limited assignment instructions document does not aid them in their job. At the other end of the scale, I’ve met with officers who are baffled by a 100-page collective that bears little relevance to their job and duties.

In our experience, assignment instructions are a constant reference for the security officer and every bit as important as his or her licence and uniform. Having passed Basic Job Training, the assignment instructions become a familiar document which includes such important information as duties for the security staff, client details and emergency procedures.

Advantages of detailed instructions

The advantages to having detailed but concise assignment instructions are far-reaching:

• it’s one of the requirements of the SIA’s Approved Contractor Scheme
• Security officers are more confident in their job, and have a standard against which they can work
• they portray a professional image to clients
• the guarding company’s processes are more structured
• it’s good indication to your insurers that you’re trading correctly

However, when producing your assignment instructions you’ll find that it’s time-consuming and very often difficult to know what to include. The instructions we’ve developed are easily adaptable and contain information approved by a qualified assessor

Roberta Minty is Managing Director of the Total Training Consultancy.

You certainly make the importance of assignment instructions obvious. In addition, I like how you point out that these documents can be a source of confusion. If the document is too extensive, or not extensive enough, a company can end up paying for security service that they are not using to it’s full potential. http://www.goldshieldsecurity.com/brooklyn-ny-security-officers-and-fire-guards.htm

How long legally do site security assignment instructions last, ie need renewing and signing by security staff ?

The British Standards say they must be reviewed upon any change or at least annually

Assignment Instructions Tutorial  

Welcome to the assignment instructions tutorial. In this article we’ll take a look at the SIRV decision tree feature to build a specific type of procedure, assignment instructions.

The decision tree feature is ideal for anyone looking to formalise procedures and promote compliant behaviour.

Most organisations record procedures using traditional methods such as flow charts stored in a PDF format. The SIRV decision tree feature has significant benefits over this method. 

Business Case: 4 Reasons for Decision Trees

1) compliance & best practice.

Most procedures are made and then left on a shelf somewhere, only to be seen once a year.

A SIRV decision tree can be seen real-time in the field at any time.

The availability and accessibility of the SIRV decision tree gives users the opportunity to check whether their decision making complies with best practice.

2) Relevant

We work in a rapidly changing world that often calls for changes in procedures. However, changing paper based procedures is time consuming.

With SIRV, any change to a procedure is reflected instantly.

3) Claims Defence

The SIRV decision tree audit feature tracks each time a user accesses and follows a procedure.

This is particularly valuable when making a claims defence.

4) Refresher Training

You can use the decision tree feature to refresh training.

It is easy to take users through a decision tree and ask questions. The audit feature means you can track performance. Ideal for refresher training or inducting new people on site.

Take me straight to the user tutorial

Background: What is a Decision Tree?

We are really excited about the decision tree feature. It can have a real impact on people’s decision making and behaviour.

Organisations will deploy our decision tree feature for:

• Disaster recovery plans
• Safety protocols
• Cleaning procedures
• Assignment instructions (Security)

People use decision trees in many walks of life, in particular finance, software and engineering. However, our inspiration came from the commercial aircraft market, which in-turn took their lead from the United Stated Air Force.

Aircraft Crashes

Back in 1935 the United States Army Air Corp found flying aircraft had become so complex that pilots were unable to process all the aircraft’s different functions. For example, during a flight contest in which a brand new Boeing long range bomber took off, climbed 300 feet, stalled and crashed killing two of the five crew. The complexity was too much for the crew during during take off. As a solution the aircraft industry began unburdening pilots by giving them checklists to complete.

(Further information available in Checklist Manifesto ). 

Today these checklists have developed into decision trees. If they face a problem on an aircraft know not to compute all their options. Instead, they are taught to consult their checklists and decision trees.

The aircraft industry saw the human mind cannot be relied to quickly decide in life and death situations.

Decision Trees vs Assignment Instructions

Assignment  instructions are specific procedures for security guards. Although security guards do not fly planes they do face high impact, low frequency events. Whether it is checking suspicious items or assessing a water leak above a tech room, they too can benefit from the clarity of a decision tree.

Paper based assignment instructions have the following drawbacks:

• Slow: Not all the information assignment instructions contain is relevant to a decision maker, for example version numbering. Therefore, decisions are slow.
• Unclear: The unstructured format of assignment instructions means procedural guidance is vague.
• Hard work: There is a natural resistance to ploughing through dense, word heavy documentation, particularly in a time pressured situation. 
• Inaccessible: Files containing assignment instructions are usually stored in a control centre. As a result, decisions made are remote from the decision maker in the field.

In contrast, decision trees are quick, easy to follow, prescriptive and accessible. 

Decision Trees vs Flow Charts

If you already have flow charts you may have something very similar to a decision tree.  However, the SIRV decision tree feature differs from a flow chart in two important ways:

1) To reduce uncertainty the SIRV decision tree provides a fixed structure. For example, you can only ask one question at a time. 

2) A flow chart on paper allows the decision maker to review the entire flow chart. SIRV limits the decision maker to viewing only one question and its respective answers. This clarity helps the user concentrate on the decision at hand.

Foreground: How to Build a Decision Tree

We’ll look at the SIRV decision tree feature by breaking it down into three areas:

Building a Basic Decision Tree

Editing a decision tree

• Insert level
• Delete level

Advanced features

• Ending in another decision tree
• Ending in another branch of the same decision tree
• End in an incident or event

Audit Trail

Designing your first Decision Tree

You can dive straight into building a decision tree. However, if you’re writing a complex procedure / assignment instruction, you’ll soon find a decision tree’s logical structure demands some forethought.

Important considerations:

• A decision tree follows the format of one question and one or more answers. Each question and answer(s) represent a level.
• A link between decision tree branches is possible.
• A link between decision trees is possible.
• The decision tree user can only view one question and answer(s) at a time.

Unlike many assignment instructions, decision trees are highly prescriptive. If you already have written procedures you will find ‘fuzzy instructions’ inappropriate. For example, an assignment instruction can set a task such as ‘Contact Gold Command’. But, should communication be through phone, email or text? Decision trees are a great way to eliminate confusion and be prescriptive.

Whenever we help organisations build their decision trees we stress test their logic by drafting the decision tree on a white board or large A3 sheet of paper before commencing the build in SIRV.  This is time well spent.  

Do & Review

Building a decision tree can take as little or as much time as you like. Regardless of complexity whenever you are building a decision tree ensure you regularly save it.

When you review a decision tree ensure you view its appearance on the screen the decision maker will use. Information displayed on a 15 inch landscape laptop looks very different on a 4 inch portrait mobile phone.

In the following video we look at building a simple three level decision tree. We name the tree and add the following elements: 

Edit a Decision Tree

Edit a decision tree at any time. once changes are made the decision tree will automatically update., sometimes a decision tree is built but a new question is needed or one needs to be taken away. in the following video we look at editing a decision tree by:.

• Add a level 
• Delete a level

Advanced Features

Here are some advanced decision tree features:.

A gateway stops the user advancing to another level until they have answered positively (Yes) to your question(s). If an answer is negative (No) the user is unable to progress to the next level in the decision tree.

Ending a decision tree branch at the start of another decision tree

Often one assignment instruction / procedure will refer to another assignment instruction / procedure. For example, assignment instructions for suspicious items or fire alarms will often refer to the same evacuation assignment instruction. SIRV allows a link in any branch to the start of another decision tree. 

Link a branch in a decision tree with another branch in the same decision tree 

This allows a link to one branch in a decision tree to another branch in the same decision tree.

Ending a decision tree branch in an incident or event form

At the end of a branch you may want the user to be asked to complete an incident or event form. 

Every time you view a decision tree it records:

• Who saw the decision tree and when
• Route taken through the decision tree

This information is shown through a usage search, shown in the video below.

The pay back for investing time in decision trees is obvious and rapid. Users have power to make better decisions locally and management receive fewer queries. Building a decision tree is simple and some would say fun. 

The following decision trees are available, ready built when you purchase SIRV:

• Business Continuity Plan
• Bomb Threat Received
• Ejecting People
• Lift Entrapment
• Transport Safety
• Vehicle Accident
• Vehicle Breakdown
• Work at Height

You can also download more procedures and assignment instructions here .

Download Now: Assignment Instructions

Ready to download:

> Business Continuity Plan

> Bomb Threat Received

>   Lift Entrapment

> Media Release

> Ejecting People

Popular Articles

Proof of Presence for Dummies: Designing your first guard patrol

Top 3 Security Guard Phones

Privacy Policy

Address: SIRV Systems Limited, 85 Great Portland street, First Floor, London, UK W1W 7LT

Get in touch

Text & WhatsApp: (0) 7984 884404

Email: [email protected]

Web Chat: Use the web chat pop-up

2016  Communication Product (Winner)

2017  Communication Product (Finalist)

2018  Start-up of the Year (Finalist)

2019  Innovation of the Year (Finalist)

2020 Innovation of the Year (Finalist)

2021 Innovation of the Year (Finalist)

2022 Innovation of the Year (Finalist)

2023 Innovation of the Year (Finalist)

Privacy Overview

Get great content straight to your inbox

Join our mailing list to receive the latest news and updates from our team.

GDPR Consent I consent to receive emails with updates, news and offers from SIRV only

Terms and Conditions I agree to Terms and Conditions

You have Successfully Subscribed!

• Our Audit Process
• SOC 1 Audits
• SOC 2 Audits
• HIPAA Audits
• HITRUST Certification
• FedRAMP Compliance
• StateRAMP Assessment
• CMMC Compliance Assessment
• Penetration Testing
• Leadership Team
• What is SOC 2?
• What is a SOC 2 Report?
• What is SOC 1?
• 2022 Trust Services Criteria (TSCs)
• Audit Terms

Security Procedures – How Do They Fit Into My Overall Security Documentation Library?

I’ve written previously about the importance of security policies and provided some basic principles for developing solid security policies. This blog post builds upon the foundation of security policies and discusses the importance of security procedures and how they fit into your overall security documentation library. Below are a few principles to keep in mind of when drafting (or reviewing existing) security procedures.

What are Security Procedures?

Security procedures are detailed step-by-step instructions on how to implement, enable, or enforce security controls as enumerated from your organization’s security policies. Security procedures should cover the multitude of hardware and software components supporting your business processes as well as any security related business processes themselves (e.g. onboarding of a new employee and assignment of access privileges).

The Purpose of Security Procedures & Why They’re Needed in an Organization

The purpose of security procedures is to ensure consistency in the implementation of a security control or execution of a security relevant business process. They are to be followed each time the control needs to be implemented or the security relevant business process followed. Here is an analogy. As part of every aircraft flight, the pilot will follow a pre-flight checklist. Why do they do this? Simply put, they do it to ensure that the aircraft is ready to fly and to do everything possible to ensure a safe flight. Although pilots may have flown thousands of hours, they still follow the checklist. Following the checklist ensures consistency of behavior each and every time. Even though they may have executed the checklist hundreds of times, there is risk in relying on memory to execute the checklist as there could be some distraction that causes them to forget or overlook a critical step.

Much like pre-flight checklists, security procedures guide the individual executing the procedure to an expected outcome. One example is server hardening. Even though a system administrator has built and hardened hundreds of servers, the procedure to harden the server still needs to be followed to ensure the server is hardened correctly and to a level that still allows operability with the system of which it is a part. If the hardening procedure is not followed, the system administrator could leave out a step that results in an unacceptable exposure of the server or data (e.g., leaving unneeded ports open on the server or the permissions on a directory open to unauthorized users). The best option would be to automate the hardening procedure through scripts or other automation tools (e.g. Puppet or Chef). This will ensure the consistent execution of the hardening “procedure.”

What is the Relationship Between Security Policies and Security Procedures?

• Security procedures build upon your organization’s security policies. Your organization’s security policies are the foundation of its security program. An important principle of security policies is that they focus on guiding behavior. Like security policies, security procedures also focus on guiding behavior. While security policies address the who, what, and why, security procedures inform individuals in your organization of the when (e.g. daily, monthly, upon a certain trigger), where, and how relating to security. To help focus the security procedures within your organization, standards and baselines should also be defined. Standards and baselines are directed at the technology implemented in an organization, whereas policies and procedures focus on guiding behaviors. As depicted below, think of the relationship between policies, standards, baselines, and procedures like a triangle with security policies as the base or foundation:

The following is an example of how security procedures build upon or enable security policy. Your organization has defined a policy (who, what, and why) regarding the creation of backups for critical information. The supporting security procedure should define when the backups are executed, to what location and medium the backups are written, and how the individual steps to execute the backup are performed. Whether dealing with specific technology or a security-relevant business process, write a procedure for all areas where repeatable and consistent application or enforcement of controls is needed. Remember, procedures are meant to guide an individual’s behavior to obtain a certain and desired end result.

• Security Procedures should contain sufficient detail to be executable. Security policies outline security needs in a general or high-level fashion. Security procedures, on the other hand, must provide sufficient detail that an individual who is not familiar (or mildly familiar) with the process or technology can successfully reach the desired outcome for the procedure. Many organizations have those one or two superstar tech geniuses who know how to do everything. While it is good to have such talent on your staff, it ultimately represents a risk to your organization if security procedures are not put in place. What would be the response if your superstar is out on vacation when his or her knowledge of how to do something is suddenly needed? Avoid such circumstances by developing security procedures to define the how, where and when things get accomplished. Beware to avoid developing procedures that rely on expert knowledge as a foundation to execute the procedure, doing so often results in gaps in the procedure. A good test for the level of detail for your procedure is to have some of your more junior staff execute the procedure. If they can do it cleanly, then there is likely sufficient detail to your procedure. If not, provide additional detail to your procedure. Also, make sure everyone who may execute the procedure has the proper access/permissions.

Why Is It Important To Keep Security Procedures Current?

Just as security policies should be reviewed and updated on a regular basis, security procedures need the same care and feeding. For those procedures that are executed on a regular basis (e.g. daily or monthly), the review should occur as part of the execution of the procedure. Just make sure any updates are made in a timely manner. For procedures that are executed on a less frequent basis (e.g. on a specific trigger like a disaster or incident) these procedures need to be reviewed and exercised at a minimum of once per year or as part of the “post-mortem” activities of an actual disaster or incident. Technological changes in your organization will drive the need to update your procedures, and new procedures should be created as part of the overall implementation plan for the new technology. Maintaining current security procedures will ensure safeguard your organization against inadvertent actions or other errors regarding the implementation of security controls, especially in stressful situations or time crunches.

Security policies and procedures are a critical component of an organization’s overall security program. With defined security policies, individuals will understand the who, what, and why regarding their organization’s security program, but without the accompanying security procedures, the actual implementation or consistent application of the security policies will suffer. Linford and Company has extensive experience writing security policies and procedures. If you would like to learn more about how Linford and Company can assist your organization in defining security policies and procedures or other services such as FedRAMP , HITRUST , SOC 1 or SOC 2 audits, please contact us.

Ray Dunham started his career as an Air Force Officer in 1996 in the field of Communications and Computer Systems. Following his time in the Air Force, Ray worked in the defense industry in areas of system architecture, system engineering, and primarily information security. Ray leads L&C’s FedRAMP practice but also supports SOC examinations. Ray enjoys working with clients to secure their environments and provide guidance on information security principles and practices.

Related Posts:

• Enterprise Security — 5 Steps to Enhance Your Organization's Security
• Security & Privacy: You Can’t Have Privacy Without Security
• Mobile Security Threats: What You Need To Know For SOC 2
• AI & Security: How Will It Affect Your Organization?
• What is the CMMC (2.0)? New DoD Guidance for Security Compliance
• What is a Security Operations Center (SOC) & Why Should You Invest in One?

Shopping Cart

No products in the cart.

III.A – Post Orders & Assignments

California Security Officers with Registrations (guard cards) must receive 40 hours of training as follows:

• 8 hours “Powers to Arrest” prior to an Officer standing post.
• 16 hours of training within 30 days of issuance of registration, 8 of which must consist of two four-hour courses from the mandatory modules and 8 of which must consist of elective course.
• 16 hours of training within 6 months of issuance of registration, 8 of which must consist of the remaining two four- hour courses from the mandatory modules, and 8 of which must consist of elective course.

This course module, titled “Post Orders & Assignments” is in compliance with Business and Professions Code Sections 7583.6 and 7583.7 and Title 16, Division 7, Article 9, Section 643 of the California Code of Regulations.

This course corresponds to module III.A of the BSIS Course Outline. This is a elective course under the Course Outline and satisfies the requirement for 4 hours of training under the elective section of the Security Officer Training Laws and Regulations.

III.A Post Orders & Assignments – 4 hours

Course outline & syllabus learning goals.

• The officer will be provided with an understanding of company specific or site specific post orders for their company or job site.
• The officer will be provided with an understanding of the basic training required to function properly while on post.
• The officer will be provided with an understanding and working knowledge of all equipment necessary for the security officer to perform their task.
• The officer will be provided a basic understanding of the procedures to implement during an emergency.
• The officer will be provided a basic understanding of the legal liabilities of their actions and personal conduct while working as a security officer.
• The officer will be provided information on the recording and safe storage of lost/found articles.

Site Specific Training/Site Orientation (Note that your employer or job site will likely have specific Post Orders that should supersede any information )

• Reporting on-duty procedures
• Review with relief officer of significant issues/events
• Review of on-site Post Order/Instructions
• Preparation of DAR (Daily Activity Report)
• Review of CCTV Monitoring equipment
• Review and inspection two-way radio, telephone and any other communication devices
• Review of fire alarm control panel, weather radio and other emergency equipment
• Review of Intrusion alarm control panel and access control systems
• Inspection of elevator or fire exit monitors to ensure

Emergency Response Issues

• Review of Emergency procedures
• Identify facility personnel on-duty who serve as EMTs or emergency response team members
• Review emergency notification call list

Liability Implications

• Review of all instructions and training checklists to ensure all security personnel have received adequate training and understand post order instructions
• Issues related to negligence and malfeasance to be discussed

Lost/Found Articles

• Review of procedures to follow when an item is given to security
• Documentation and witness verification
• Proper security of the items
• Periodic inventory and review of lost/found articles
• Credibility issues involving failure to properly document the items

Other post duties as required, including review of:

• Escorts of client personnel before and after hours
• Parking / traffic enforcement and notices
• Energy management duties, lighting and water monitoring and control

Course Content

About instructor.

Course Includes

• Course Certificate

Email Address

Remember Me

• Administering Oracle Fusion Analytics Warehouse
• Manage Users, Groups, Application Roles, and Data Access

Manage Data Access through Security Assignments

As a security administrator, you need to map data security assignments to users to enable data level access.

Use the Security Assignments tab on the Security page to search for the currently set up data security assignments. You may either search for all records or narrow your search to a specific security context, security value, or user. You can remove a security assignment that you had set up or add new security assignments to a user.

Create a Security Assignment

Delete a security assignment, remove users from a security assignment, manage users for a security assignment.

• Upload and Download Data Security Assignments

Use these instructions to create a security assignment in a specific security context.

• Sign in to your service.
• In Oracle Fusion Analytics Warehouse , open the Navigator menu, click Console , and then click Security under Service Administration . You see the Security page.
• On the Security page, click the Security Assignments tab. You see all users who have been granted the security assignments in a specific security context.
• Click New Assignment .
• In New Security Assignment, under Select Security Assignments , select a security context, and then search for a security value or select from the displayed list.Move the selected security assignments to the column on the right.
• Under Select Users , search for a user and select the user and move the user to the column on the right. Users are filtered based on the role associated with that context.
• Click Add to Cart and then click View Cart .
• In Security Assignments, click Apply Assignments . You can grant this security assignment to other users as required. Bulk assignments may take some time to process. See the Security Activity tab for details.

Use these instructions to delete a security assignment. When you delete a security assignment, Oracle Fusion Analytics Warehouse removes all users associated with the security assignment.

• On the Security page, click the Security Assignments tab.
• Select a security assignment from the displayed list of assignments or search for a security assignment and select it.
• Click Delete Assignment .

You can revoke the security assignment granted to one or more users.

• In the security assignment details region, select the users from the displayed list of users or search for and select the users.
• Click Remove User .
• In Revoke User Assignment, click Revoke Assignment .

As a security administrator, you can manage users for existing data security assignments. In the Manage Users dialog, you can revoke users for an existing assignment or add new users for that assignment.

• In the security assignment details region, click Manage Users .
• Under Add User , search for a user and select the user.
• Under User , click the Delete icon to revoke the user from the assignment.
• Click Save .

Do you have a question about how to do something or need more information about a topic? This toolkit will quickly point you to the resources you need to help you perform your role in Physical Security. Select a category to start accessing resources.

Physical Security Planning

Electronic security systems.

• Security Measures

Storage Containers/Facilities

• Specialized Security Requirements
• Professionalization

• eLearning:  Risk Management for DOD Security Program  GS102.06

Physical Security Plan Creation

• eLearning:  Physical Security Planning and Implementation  PY106.16, Lesson 4

Design and Constructions Standards

Antiterrorism Considerations

Emergency Preparedness

• Short:  Classified Storage Requirements
• Military Handbook 1013/1A, Design Guidelines for Physical Security of Facilities, 15 December 1993, Sections 4 and 5  

Additional Resources for Access Control

• Short:  Functions of Entry Control Facilities (ECFs)/Access Control Points (ACPs)

Physical Security Measures

Additional resources for barriers, fences, gates, additional resources for lighting.

• Short:  DOD Locks Approved to Safeguard Classified and Sensitive Materials
• Video:  Operating and Closing the X-10 Electromechanical Combination Lock
• Video:  Changing the Combination of the X-10 Electromechanical Combination Lock
• Video:  Operating the S&G 2740B Electromechanical Safe Lock
• Video:  Changing the Combination of the S&G 2740B Electromechanical Safe Lock
• Video:  Operating S&G 2740 Locks
• Video:  Changing the Combination of S&G 2740 Locks
• Video:  Operating X-07 and X-09 Locks
• Video:  Changing the Combination of X-07 and X-09 Locks

Additional Resources for Vaults

Key resources, key documents and forms.

• Short:  Completing the SF 700
• Short:  Completing the SF 701
• Short:  Completing the SF 702

Specialized Areas

• Short:  How to Conduct an Inspection - Helpful Tips

Additional Resources for SCIFs

Additional resources for aa&e, additional resources for nuclear weapons.

Note: The courses listed below are suggestions only. Please check with the appropriate authority to ensure a specific course will count towards your professional development.

Security Professional Education

• CDSE Security Professional Program

SPēD Certification

• Security Professional Education Development Program (SPēD)

CDSE Program (by discipline)

• Program:  Basic Industrial Security for the Government Security Specialist  IS050.CU
• Program:  FSO Orientation for Non-Possessing Facilities  IS020.CU
• Program:  FSO Program Management for Possessing Facilities  IS030.CU

Other Agency Courses

• eLearning:  Operations Security (OPSEC) Overview (DoE)
• Shorts:  Information Assurance Awareness Shorts (DISA)

Due: Sat May 25 11:59 pm Late submissions accepted until Sun May 26 11:59 pm

Assignment by Michael Chang & Julie Zelenski idea originated by Randal Bryant & David O'Hallaron (CMU). Modifications by Nick Troccoli, Brynne Hurst, Kathleen Creel and Jonathan Kula.

Learning Goals

This assignment focuses on understanding assembly code representations of programs. You will be building your skills with:

• reading and tracing assembly code
• understanding how data access, control structures, and function calls translate between C and assembly
• reverse-engineering
• understanding the challenges of writing secure and robust systems
• understanding privacy, trust, and the role of the ethical penetration tester
• mastering the gdb debugger!

You have been hired as a security expert for Stanford Bank (a fictional on-campus bank). They need you to investigate reports of infiltration and security issues and replicate the issues so that they can fix them.

There are three parts to this assignment, each of which can be completed independently:

• an ATM withdrawal program containing some vulnerabilities - you'll need to use your C and assembly skills to find and demonstrate how to exploit these vulnerabilities.
• A dataset that you will use to deanonymize bank users.
• The SecureVault program, a new product designed by the bank to provide increased security to the master vault. You'll be given an executable of the SecureVault program (no C code provided!) to show that it is possible to reverse engineer this program and break into the master vault without being told the passwords.

These problems are like C/assembly "puzzles" to solve, and we hope you enjoy solving them and exploring this material as much as we enjoyed creating them!

Note: check out our assignment overview video on Canvas ; it goes over the different parts of the assignment, what to expect, and tips and tricks! Note the overview video is from this quarter last year, but the assignment is the same (save for the fact that questions 2 and 3 are exchanged).

Spring 2024: Lecture 22 (Mon 5/20) is necessary to work on questions 3 and 4 in part 2 of this assignment.

A few reminders:

• The working on assignments page contains info about the assignment process.
• The collaboration policy page outlines permitted assignment collaboration, emphasizing that you are to do your own independent thinking, design, writing, and debugging. Even without any code being submitted, you should not be doing any joint debugging/development, sharing or copying written answers, sharing specific details about SecureVault behavior, etc. If you are having trouble completing the assignment on your own, please reach out to the course staff; we are here to help!

To get started on this assignment, clone the starter project using the command

View Full Starter File List

• vault : Your SecureVault executable program, custom-generated for each student.
• custom_tests : The file where you will add custom tests to reproduce vulnerabilities in the provided ATM withdrawal program.
• input.txt : A blank text file where you should add the passwords for each SecureVault level, one per line. See the section on SecureVault for more information.
• readme.txt : A file where you should add answers to short written questions for all three parts of the assignment.
• .gdbinit : A gdb configuration file you can optionally use to run certain gdb commands each time gdb launches. See the section on using GDB in SecureVault for more information.
• samples : A symbolic link to the shared directory for this assignment. It contains:
• atm : The executable ATM program, which you will explore for vulnerabilities.
• atm.c : The C source code for the ATM program, which you will explore for vulnerabilities. Note that you're not able to edit or recompile this code/executable.
• checkins.csv : A file containing public social media location check-in data for various locations on Stanford campus over the past three months.
• search_checkins : An executable program to search the check-in data.
• bank : a folder containing the following:
• customers.db : A file with the list of all users and balances for the ATM program.
• transactions.csv : A file with ATM transaction information from the past three months at the Stanford campus ATM.
• SANITY.INI and sanity.py : Files to configure and run sanity check. You can ignore these files.
• wordlist : A list of dictionary words used for SecureVault.
• tools : Contains symbolic links to the sanitycheck and submit programs for testing and submitting your work. ( codecheck is not needed on this assignment)

You will be using gdb frequently on this assignment. Here are essential resources as you work - note that you should make sure you have downloaded the CS107 GDB configuration file mentioned in the Getting Started Guide if you didn't previously do so.

Open Getting Started Guide Open GDB Guide Open Lab5 GDB Tips Open Lab6 GDB Tips

1. ATM Security

Stanford Bank recently updated the ATM software to a version with some additional features. The IT team reviewed the new code and thought it all looked good, but having now installed it in production, they are observing some suspicious activity. The bank has called you because your superior C and assembly skills are just what's needed to investigate and resolve these problems!

In the samples folder, they have provided you the code ( atm.c ) and compiled executable ( atm ), which you can examine/run but cannot recompile or edit (since they want to ensure you work with the same executable installed on the ATMs themselves). The ATM program is invoked with an amount and the credentials for a particular account. If the credential is authorized and the account has sufficient funds, the amount is withdrawn and dispersed in cash. Accounts must maintain a minimum balance of $50, and the ATM is supposed to maintain bank security by rejecting unauthorized access. Every time you run the program, it will print out information to the terminal about the transaction that took place, or the error that occurred, if any. For example, if you ask to withdraw $100 from your account balance of $107, it should be denied with an error message because that would bring your current $107 balance below the required minimum of $50. If you try to sneak cash from another account or use a fake name, your credential should get rejected as unauthorized.

Here are a few examples - try it out yourself! Note that $USER automatically acts as your SUNET ID, and every account balance is set to be $107. Also, each time you run the program anew, all balances return to their original starting levels. No money actually changes hands in this ATM, which is a blessing given its security flaws.

Expand ATM Sample Runs

The bank has identified three anomalies in the ATM program behavior that they need your help investigating. For each of the anomalies (a), (b), and (c) below, you will need to do the following:

• include a test case in your custom_tests file to showcase how to reproduce the vulnerability. Note that there may be more than one way to trigger a vulnerability.
• A concise description of the underlying defect in the code.
• An explanation of exactly how you constructed your test case to exploit it.
• Your recommendation for fixing it. The bank is not looking for a major rewrite/redesign, so in your proposed changes you should directly address the vulnerability with minimal other disruption. Note that there may be more than one possible remedy for fixing each issue. Also make sure you do not remove intended functionality of the bank program, and account for any potential additional security issues introduced by your proposed fix .

NOTE: when running your own custom tests, make sure to inspect the output to ensure your tests are causing the behavior you expect! The sanitycheck tool itself does not verify that the tests cause the specified exploits.

As you work through your investigation, you will need to review the source code for the atm program. The program is roughly 175 lines of C code of similar complexity to what you have been writing this quarter, and is decomposed and fairly readable, though sorely lacking in comments. You should find that the program's approach seems reasonable and the code is sincere in its attempt to operate correctly. As you're reading, take a minute to reflect on how far your awesome C skills have come to let you read through this provided program!

NOTE: when running the ATM program under GDB, make sure you are in the samples folder first before running gdb atm .

a) Negative Balances

A prior version of the ATM program restricted a withdrawal to be at most the full account balance, allowing the customer to drain their account to $0, but no further. The current version has changed the withdraw function to require a non-zero minimum balance. The expected behavior should be that all account balances stay above this minimum. However, the bank saw an (otherwise ordinary) withdrawal transaction that not only caused an account to go below the minimum, but also overdrew so far as to end up with a negative balance. Oops, that's definitely not supposed to happen! Review the C code for the withdraw function, specifically the changes from the old version. It seems to work in many cases, but apparently not all. Read carefully through this function to try and discover the flaw - your understanding of signed and unsigned integers will be useful here! Once you have found the vulnerability, determine a command to make a withdrawal as yourself that withdraws more money than is present in your account . Put this command in custom_tests , and answer the specified readme questions.

b) Unauthorized Account Access

The bank has also received a customer complaint about an unauthorized withdrawal from their account. It seems that another user with different credentials was able to successfully withdraw money from the aggrieved customer's account. Moreover, the credential used appears to be entirely fake - no such user exists in the database! A user should not be able to access a different customer's account and especially not by supplying a bogus credential! Review the C code for the find_account function that is responsible for matching the provided username to their account number. It seems to work properly when the username matches an existing account, but not when the username doesn't match an existing account. Trace through line by line how the function executes when called with an invalid username that is not in the database. What lines are executed? Once you do this, you'll find that the function appears to behave unpredictably. Your next task is to examine the generated assembly to determine precisely how the function will behave - your understanding of the %rax / %eax register will be useful here! Once you have found the vulnerability, determine a command with a designed bogus name credential to withdraw $40 from one of the CS107 staff member's accounts. Put this command in custom_tests , and answer the specified readme questions. (The samples/bank/customers.db file contains information about all valid users and their balances, and the first 15 users in the database are staff accounts.)

c) Accessing The Master Vault

The most worrisome issue is repeated illicit withdrawals from the master vault account, account number 0. The name on the master account is not an actual user, so this account cannot be accessed using the simple username-based credential. Instead, the user must specify two account arguments, the account's number and its secret passcode, as a form of heightened security, like this:

At first the bank thought the vault passcode had been leaked, but changing the passcode did nothing to thwart the attack. In a fit of desperation, the bank removed the vault passcode file altogether, figuring this would disable all access to the vault, yet the rogue user continues to make withdrawals from it! It seems that the high-security passcode authentication may have its own security flaw! The code that handles this authentication is in the lookup_by_number and read_secret_passcode functions. These functions work correctly in many situations, but fail in certain edge cases. Remember that it seems that in certain cases supplied credentials are accepted despite the lack of a saved passcode file . The vulnerability is subtle in the C code, so you should also use GDB to examine the code at the assembly level and diagram out the memory on the stack for these functions . This problem is similar to the stack diagramming/exploit problem from lab6 - revisit that problem if you need a refresher! Your exploit should not involve reading from any file. Once you have found the vulnerability, determine a command to withdraw $300 from the bank vault despite its disabled passcode . Put this command in custom_tests , and answer the specified readme questions.

2. Dataset Aggregation

Separate from the faulty ATM software, Stanford Bank believes that someone was able to gain access to their account logs and get a list of ATM transaction information for their Stanford campus ATM. The company believes that this poses little threat because the transaction logs have limited recorded data. However, you are concerned that this data can be combined with other available data in dangerous ways, such as to learn private information. For instance, knowing someone's history of large (or small) transactions might tell you about their financial situation; knowing memberships in clubs or organizations might tell you about social relationships and webs of networks. Your task is to combine this data with another dataset you have found of public location check-ins to show the harms of a potential data breach. To aid in investigating your concerns, the bank has made the ATM transaction data available to you in the samples/bank/transactions.csv file. This file has one account transaction per line, and each transaction occurred at the Stanford campus ATM. Each line has the following format:

For example, here is one line from the file that represents a withdrawal of $15 on 2/15/21 at 4:54PM:

Transactions with the same account identifier are guaranteed to be for the same bank account, but the identifier doesn't give any information about whose account it is (intentionally done by the bank to obfuscate the data).

You have already downloaded a publicly-available location checkins dataset from an online social network, in the file samples/checkins.csv . It is too large to read through manually, so you also already created a program search_checkins that displays that checkin data and lets you search through it more easily. Run the program ( samples/search_checkins ) for instructions on how to use it.

Show the risks of dataset aggregation and express your concerns to the bank managers by answering the following questions in your readme.txt . Note that you are not expected to create any additional programs to parse or otherwise process these datasets with code - the intent is for you to skim the transactions.csv file by hand and use it along with the search_checkins program to answer the following questions.

• a) The likely user who made multiple large transactions?
• b) Two (there may be more, but you must identify only two) likely members of the Stanford SecurityStars Club, which has a club meeting on the 15th of each month where people must bring $15 to pay their membership dues? (Assume they are procrastinators in withdrawing the money)
• How were you able to de-anonymize the transactions data?
• Beyond encrypting the data, what recommendations would you give to Stanford Bank to further anonymize or obfuscate the account data in the case of accidental data breaches?
• Use one or more of the four models of privacy discussed in lecture to explain why disclosure of the information that can be aggregated here is (or is not) a violation of privacy.

3. SecureVault

Stanford Bank is rolling out a new tool, SecureVault, to provide increased security at the master vault at each of their branches. Employees must enter four secret passwords into this program to gain access to the master vault. For extra security, the bank creates a different SecureVault program for each branch with different expected passwords; the bank headquarters does not give the source code to any of the branches; and the program triggers an alarm that notifies the central system each time an incorrect password is entered. They are confident that this means only someone who is told the password can get access, and any potential intruders will be detected by the alarm system. They have hired you to test this. Your task is to show that you can reverse engineer the program to gain access to the bank vault without being told the password, and without alerting central security.

Do not start by running SecureVault and entering passwords to "see what will happen" . You will quickly learn that what happens is the alarm goes off and it deducts points :-) When started, SecureVault waits for input and when you enter the wrong password, it will raise the alarm and notify the central system, deducting points. Thoroughly read the SecureVault information below before attempting to enter any passwords! There is a lot of information below, but it is included to help provide useful tips for you to work through this part of the assignment.

Without the original source code, all you know is that SecureVault has four "levels" of security, each with a different password. If the user enters the correct password, it deactivates the level and the program proceeds on. But given the wrong input, SecureVault raises an alarm by printing a message, alerting central security and terminating. To reach the master vault, one needs to successfully disarm each of its levels.

This is where the bank needs your help. Each of you is assigned a different generated SecureVault executable unique to you, generated just as they would be for each bank branch. Your mission is to apply your best assembly detective skills to reverse engineer the SecureVault executable to work out the input required to pass each level and reach the master vault, thus proving the insecurity of the bank's approach.

Specifically, you must fill in your input.txt file with the passwords to defuse each level in order, 1 per line, for each level you have solved. You must also answer the following questions in your readme.txt file. Make sure to verify your input.txt file (with appropriate protections!) to ensure proper formatting and that all lines are entered correctly before submitting! We will test by running ./vault input.txt on your submission, using the original SecureVault program generated for you. Here are the readme questions to work through as you go:

• What tactics did you use to suppress/avoid/disable alarms?
• level_1 contains an instruction near the start of the form mov $<multi-digit-hex-value>,%edi . Explain how this instruction fits into the operation of level_1 . What is this hex value and for what purpose is it being moved? Why can this instruction reference %edi instead of the full %rdi register?
• level_2 contains a jg that is not immediately preceded by a cmp or test instruction. Explain how a branch instruction operates when not immediately preceded by a cmp or test . Under what conditions is this particular jg branch taken?
• Explain how the loop in the winky function of level_3 is exited.
• Explain how the mycmp function is used in level_4 . What type of data is being compared and what ordering does it apply?
• How would you describe Stanford Bank’s trust model? (In other words: who among the bank headquarters, the bank branches, and you was trusted?) Justify your answer.

SecureVault Information

From the SecureVault assembly, you will work backwards to construct a picture of the original C source in a process known as reverse-engineering . Note that you don't necessarily need to recreate the entire C source; your goal is to work out a correct input to pass the level. This requires a fairly complete exploration of the code path you follow to deactivate the level, but any code outside that path can be investigated on a need-to-know basis. Once you understand what makes your SecureVault program "tick", you can supply each level with the password it requires to disarm it. The levels get progressively more complex, but the expertise you gain as you move up from each level increases as well. One confounding factor is that SecureVault raises an alarm whenever it is given invalid input. Each time the alarm goes off (except for a free pass the first time), it notifies central security (the CS107 staff) and points are deducted from your score. Thus, there are consequences to setting off the alarm -- you must be careful!

The bank has confirmed to you a few things about how the SecureVault programs operate:

• If you start SecureVault with no command-line argument, it reads input typed at the console.

If you give an argument to SecureVault, such as input.txt :

SecureVault will read all lines from that file and then switch over to reading from the console. This feature allows you to store inputs for solved levels in input.txt and avoid retyping them each time.

Alarms can be triggered when executing at the shell or within gdb. However, gdb offers you tools you can use to intercept the alarms, so your safest choice is to work under gdb and employ preventive measures.

• It is not possible to know for sure whether the central system (course staff) is notified about an alarm. You must use your investigative skills and best defensive measures!
• The central system will give you a free pass (no point deduction) the first time they are notified about an alarm.
• The SecureVault program in your repository was lovingly created just for you and is unique to your id. It is said that it can detect if an impostor attempts to run it and won't play along.
• The SecureVault program is designed for the myth computers (running on the console or logged in remotely). There is a rumor that it will refuse to run anywhere else.
• It seems as though the function names were left visible in the object code, with no effort to disguise them. Thus, a function name of initialize_vault or read_five_numbers can be a clue. Similarly, it seems to use the standard C library functions, so if you encounter a call to qsort or sscanf , it is the real deal.
• There is one important restriction: Do not use brute force!   You could write a program to try every possible input to find a solution. But this is trouble because a) you lose points on each incorrect guess which raises an alarm, b) trying all possible inputs will take an eternity and risk saturating the network, and c) part of your submission requires answering questions that show you understanding of the assembly code, which guessing will not provide :)

Using tools such as gdb , objdump and new tools nm and strings is critical to effectively investigating and disarming each level. Once you are familiar with the tools at your disposal, first work to reliably prevent alarms from triggering , then proceed with disarming each of the levels .

Step 1: Familiarity with Tools

Here are some helpful tools to gather general information:

• nm : use the nm utility ( nm vault ) to print what's called the "symbol table" of the executable, which contains the names of functions and global variables and their addresses. The names may give you a sense of the structure of the SecureVault program.
• strings : use the strings utility ( strings vault ) to print all the printable strings contained in the executable, including string constants. See if any of these strings seem relevant in determining the passwords.
• gdb lets you single-step by assembly instruction, examine (and change!) memory and registers, view the runtime stack, disassemble the object code, set breakpoints, and more. Live experimentation on the executing SecureVault program is the most direct way to become familiar in what's happening at the assembly level.
• Compiler Explorer : pull up tools like the Compiler Explorer interactive website from lab, or gcc on myth , to compile and explore the assembly translation of any code you'd like. For example, if you're unsure how to a particular C construct translates to assembly, how to access a certain kind of data, how break works in assembly, or how a function pointer is invoked by qsort , write a C program with the code in question and trace through its disassembly. Since you yourself wrote the test program, you also don't have to fear it setting off any alarms :-) You can compile directly on myth using a copy of a Makefile from any CS107 assignment/lab as a starting point, and then use gdb or objdump to poke around.

GDB Suggestions

GDB is absolutely invaluable on this assignment. Here are some suggestions on how to maximize your use of gdb in addition to the tips in lab5 and lab6 :

• Expand your gdb repertoire. The labs have introduced you to handy commands such as break , x , print , info , disassemble , display , watch , and stepi/nexti . Here are some additional commands that you might find similarly useful: jump , kill , and return . Within gdb, you can use help name-of-command to get more details about any gdb command. See the quick gdb reference card for a summary of many other neat gdb features.

Get fancy with your breakpoints. You can breakpoints by function name, source line, or address of a specific instruction. Use commands to specify a list of commands to be automatically executed whenever a given breakpoint is hit. These commands might print a variable, dump the stack, jump to a different instruction, change values in memory, return early from a function, and so on. Breakpoint commands are particularly useful for installing actions you intend to be automatically and infallibly completed when arriving at a certain place in the code. (hint!)

gdb kill workaround : gdb 9.2 (current version on myth as of 04/2021) has a bug when attempting to use kill in the commands sequence for a breakpoint that creates a cascade of problems --can cause gdb itself to crash or hang. The gdb command signal SIGKILL can be used as an alternate means to kill a program from a commands sequence that doesn't trip this bug.

Use a .gdbinit file . The provided file named .gdbinit in the assignment folder can be used to set a startup sequence for gdb. In this text file, you enter a sequence of commands exactly as you would type them to the gdb command prompt. Upon starting, gdb will automatically execute the commands from it. This will be a convenient place to put gdb commands to execute every time you start the debugger. Hint: wouldn't this be useful for creating breakpoints with commands that you want to be sure are always in place when running the SecureVault program? The .gdbinit file we give you in the starter repo has only one command to echo Successfully executing commands from .gdbinit in current directory . If you see this message when you start gdb, it confirms the .gdbinit file has been loaded. If you see an error message about auto-loading .gdbinit being declined when starting gdb, this means you haven't installed the CS107 GDB configuration file - see the top of this page for instructions.

• Custom gdb commands . Use define to add your own gdb "macros" for often-repeated command sequences. You can add defines to your .gdbinit file so you have access to them in subsequent gdb sessions as well.
• Fire up tui mode (maybe...). The command layout asm followed by layout reg will give you a split window showing disassembly and register values. This layout will display current values for all registers in the upper pane, the sequence of assembly instructions in the middle pane, and your gdb command line at the bottom. As you single-step with si , the register values will update automatically (those values that changed are highlighted) and the middle pane will follow instruction control flow. This is a super-convenient view of what is happening at the machine level, but sadly, you have to endure a number of quirks and bugs to use it. The tui mode can occasionally crash gdb itself, killing off gdb and possibly the SecureVault program while it's at it. Even when tui is seemingly working, the display has a habit of turning wonky, often fixable by the refresh command (use this early and often!) but not always. A garbled display could cause you to misunderstand the program state, misidentify where your SecureVault is currently executing, or accidentally execute a gdb command you didn't intend. Any alarm suppression mechanism that requires you, the fallible human, to take the right action at a critical time could easily be waylaid by interference, so don't attempt tui before you have invincible automatic protection against alarms. Selective use of auto-display expressions (introduced in lab6) is a great alternative with less disruption. You can exit tui using ctrl-x a and re-enter it again (this doesn't require leaving gdb and losing all your state).

Step 2: General Investigation and Preventing Alarms

Once you are familiar with the tools at your disposal, your next step is to gather general information about how the SecureVault program works to figure out how to reliably prevent alarms from triggering . There are simple manual blocks that give some measure of protection, but it is best to go further to develop an invincible guard. Feel free to use any technique at your disposal, such as leveraging gdb features, tweaking the global program state, modifying your setup, tricking the SecureVault program into running in a safe manner, etc. Avoiding the alarm entirely is one straightforward approach to ensure that we won't hear about it, but there are ways to selectively disable just the transmission portion to the central system (course staff) . Once you figure how to set up appropriate protection against alarms, you will then be free to experiment with the levels without worry. Note that the program can only trigger an alarm when it is "live", i.e., executing in shell or running with gdb .

Step 3: Disarming Levels

Your next task is to approach each level individually to figure out a password that disarms it. There may be more than one password for each level; your task is to enter your 4 passwords, one per line, starting with level 1, into your input.txt file. Here are key tips for how to approach your reverse engineering exploration:

• Run the program live in GDB (with appropriate alarm protections!) and step through to better understand its behavior. Reading and diagramming the assembly by hand is useful to an extent, but quickly becomes infeasible with larger programs.
• Break the assembly into chunks. For instance, if it calls any functions, that's a good stopping point to orient yourself and understand the assembly just up to that point.
• Use gdb to verify your hypotheses. Verify key assumptions you make about the vault behavior to ensure you're on the right track. One helpful trick is you can change register contents while running gdb. E.g. if you think "I believe if %rdi stored this, it would do that", then try it! You can do p $rdi = val to change register contents mid-program. Or if you think something is a char * , cast and print it out, e.g. p (char *)$rdi .
• Document your knowns and unknowns. If you run into a situation where you are stuck due to seemingly-conflicting assumptions, document them and re-verify them. If you have multiple conflicting assumptions, at least one must not be the case.
• Use compiler explorer to see what code looks like in assembly. If you think you happened upon e.g. a loop, if statement, etc. try using compiler explorer to type in some code quickly and see what that code looks like in assembly. If it resembles the assembly you're seeing, perhaps that can help you better understand its structure.
• Use library functions to your advantage. If you spot a call to what looks like a library function, it's the real deal. Use the man page for that function to learn about what parameters it takes in, what it does, and what it returns. This can give you key information about the types of data in different registers - e.g. if you see a call to strlen , then the value put into %rdi must be of type char * , and what's stored in %rax afterwards must be a size_t string length.
• When tracing an unknown function, before dissecting its behavior first learn about the input/output of the function and what role it plays. Does it return anything? What parameters does it take in? If it has a return value, is it checked to be something in particular? Going into a function with an idea of what must be returned for you to continue with the vault can help you focus on understanding how to achieve that.

Sanity Check

The default sanitycheck test cases are ATM inputs and one test case that reports the line count of your input.txt file. This sanitycheck is configured to only allow test cases for ATM in your custom_tests file. The SecureVault executable is not run by sanitycheck.

Once you are finished working and have saved all your changes, check out the guide to working on assignments for how to submit your work. We recommend you do a trial submit in advance of the deadline to allow time to work through any snags. You may submit as many times as you would like; we will grade the latest submission. Submitting a stable but unpolished/unfinished version is like an insurance policy. If the unexpected happens and you miss the deadline to submit your final version, this previous submit will earn points. Without a submission, we cannot grade your work.

We would also appreciate if you filled out this homework survey to tell us what you think once you submit. We appreciate your feedback!

For this assignment, here is a tentative point breakdown (out of 119):

• custom_tests (24 points) Each successful attack test case earns 8 points. We will test by running tools/sanitycheck custom_tests on your submission. Your custom_tests should contain 3 test cases, one for each ATM attack.
• readme.txt (55 points) The written questions will be graded on the understanding of the issues demonstrated by your answers and the thoroughness and correctness of your conclusions.
• Input.txt (40 points) Each SecureVault level you have solved earns 10 points. We will test by running ./vault input.txt on your submission. The input.txt file in your submission should contain one line for each level you have solved, starting from level 1. Malformed entries in your input.txt or wrong line-endings will cause grading failures. To avoid surprises, be sure that you have verified your input.txt in the same way we will in grading (i.e., ./vault input.txt ).
• SecureVault alarms triggered (up to 6 points deducted) Each alarm notification (beyond the first one) that reaches the staff results in a 1 point deduction, capped at 6 points total.

Post-Assignment Check-in

How did the assignment go for you? We encourage you to take a moment to reflect on how far you've come and what new knowledge and skills you have to take forward. Once you finish this assignment, your assembly skills will be unstoppable, and you will have a better understanding of trust, privacy and security! You successfully found vulnerabilities in a program using its source and assembly, and reverse engineered a complex program without having access to its source at all. Rock on!

To help you gauge your progress, for each assignment/lab, we identify some of its takeaways and offer a few thought questions you can use as a self-check on your post-task understanding. If you find the responses don't come easily, it may be a sign a little extra review is warranted. These questions are not to be handed in or graded. You're encouraged to freely discuss these with your peers and course staff to solidify any gaps in you understanding before moving on from a task.

• What are some of the gdb commands that allow re-routing control in an executing program?
• What is the main indication that an assembly passage contains a loop?
• What makes someone a trustworthy fiduciary or guardian of personal data? How and why should an institution like a bank protect the privacy of its customers?
• Explain the difference between a function's return value and its return address.
• Consider the mechanics of function pointer work at the assembly level. How is a call through a function pointer the same/different when compared to an ordinary function call?
• For performance reasons, the compiler prefers storing local variables in registers whenever possible. What are some reasons that force the compiler to store a local variable on the stack instead?
• For the instruction sequence below, what must be true about values of op1 and op2 for the branch to be taken? What changes if ja is substituted for jg ? cmp op1,op2 jg target