Consistent Sdns Through Network State Fuzzing

Total Page:16

File Type:pdf, Size:1020Kb

Consistent Sdns Through Network State Fuzzing 1 Consistent SDNs through Network State Fuzzing Apoorv Shukla1 S. Jawad Saidi2 Stefan Schmid3 Marco Canini4 Thomas Zinner1 Anja Feldmann2;5 TU Berlin1 MPI-Informatics2 University of Vienna3 KAUST4 UDS5 Abstract—The conventional wisdom is that a software-defined network (SDN) operates under the premise that the logically Policy (P) Management “Traffic A should [26-42] take Path X” (P ≣ R ) centralized control plane has an accurate representation of the Plane logical (P ≣ P ) actual data plane state. Unfortunately, bugs, misconfigurations, logical faults or attacks can introduce inconsistencies that undermine Logical + correct operation. Previous work in this area, however, lacks a Rules Logical [5, 21-25] (Rlogical) Logical Paths Topology (Tlogical) ≣ holistic methodology to tackle this problem and thus, addresses Control Plane (P ) (P Pphysical) only certain parts of the problem. Yet, the consistency of the logical [20] overall system is only as good as its least consistent part. Data Plane (P ≣ P ) Physical logical physical Motivated by an analogy of network consistency checking Rules + [2, 18, 19] (R ) physical (R ≣ R ) with program testing, we propose to add active probe-based Physical Forwarding logical physical Paths (P ) Topology (Tphysical) physical network state fuzzing to our consistency check repertoire. Hereby, our system, PAZZ, combines production traffic with Figure 1: Overview of consistency checks described in the literature. active probes to periodically test if the actual forwarding path and decision elements (on the data plane) correspond to the expected ones (on the control plane). Our insight is that active lighted by Figure1. Monocle [4], RuleScope [18], and traffic covers the inconsistency cases beyond the ones identified RuleChecker [19] use active probing to verify whether the by passive traffic. PAZZ prototype was built and evaluated on topologies of varying scale and complexity. Our results show that logical rules Rlogical are the same as the rules Rphysical of the PAZZ requires minimal network resources to detect persistent data plane. ATPG [2] creates test packets based on the control data plane faults through fuzzing and localize them quickly plane rules to verify whether paths taken by the packets on while outperforming baseline approaches. the data plane P physical are the same as the expected path Index Terms—Consistency, Fuzzing, Network verification, from the high-level policy P without giving attention to the Software defined networking. matched rules. VeriDP [20] in SDNs and P4CONSIST [21] in P4 SDNs use production traffic to only verify whether NTRODUCTION I. I paths taken by the packets on the data plane P physical are The correctness of a software-defined network (SDN) the same as the expected path from the control plane crucially depends on the consistency between the manage- P logical. NetSight [22], PathQuery [23], CherryPick [24], ment, the control and the data plane. There are, however, and PathDump [25] use production traffic whereas SDN many causes that may trigger inconsistencies at run time, Traceroute [26] uses active probes to verify P ≡ P physical. including, switch hardware failures [1], [2], bit flips [3]–[8], Control plane solutions focus on verifying network-wide misconfigurations [9]–[11], priority bugs [12], [13], control invariants such as reachability, forwarding loops, slicing, and and switch software bugs [14]–[16]. When an inconsistency black hole detection against high-level network policies both occurs, the actual data plane state does not correspond to for stateless and stateful policies. This includes tools [27]– what the control plane expects it to be. Even worse, a [37] that monitor and verify some or all of the network-wide malicious user may actively try to trigger inconsistencies as invariants by comparing the high-level network policy with arXiv:1904.08977v2 [cs.NI] 2 May 2020 part of an attack vector. the logical rule set that translates to the logical path set at Figure1 shows a visualization inspired by the one by the control plane, i.e., P ≡ Rlogical or P ≡ P logical. These Heller et al. [17] highlighting where consistency checks systems, however, only model the network behavior which operate. The figure illustrates the three network planes – man- is insufficient to capture firmware and hardware bugs as agement, control, and data plane – with their components. “modeling” and verifying the control-data plane consistency The management plane establishes the network-wide policy are significantly different techniques. P , which corresponds to the network operator’s intent. To Typically, previous approaches to consistency checking realize this policy, the control plane governs a set of logical proceed “top-down,” starting from what is known to the rules (Rlogical) over a logical topology (T logical), which yield management and control planes, and subsequently checking a set of logical paths (P logical). The data plane consists of whether the data plane is consistent. We claim that this is the actual topology (T physical), the rules (Rphysical), and the insufficient and underline this with several examples (§II-C) resulting forwarding paths (P physical). wherein data plane inconsistencies would go undetected. This Consistency checking is a complex problem. Prior work can be critical, as analogous to security, the overall system has tackled individual subpieces of the problem as high- consistency is only as good as the weakest link in the chain. 2 We argue that we need to complement existing top- in all experimental topologies while consuming minimal down approaches with a bottom-up approach. To this end, resources as compared to Header Space Analysis to detect we rely on an analogy to program testing. Programs can and localize data plane faults (§IV); have a huge state space, just like networks. There are two basic approaches to test program correctness: one is static II. BACKGROUND &MOTIVATION testing and the other is dynamic testing using fuzz testing or fuzzing [38]. Hereby, the latter is often needed as the former This section briefly navigates the landscape of faults and cannot capture the actual run-time behavior. We realize that reviews the symptoms and causes (§II-A) to set the stage for the same holds true for network state. the program testing analogy in networks (§II-B). Finally, we Fuzz testing involves testing a program with invalid, un- highlight the scenarios of data plane faults manifesting as expected, or random data as inputs. The art of designing inconsistency (§II-C). an effective fuzzer lies in generating semi-valid inputs that A. Landscape of Faults: Frequency, Causes and Symptoms are valid enough so that they are not directly rejected by As per the survey [1], the top primary causes for abnormal the parser, but do create unexpected behaviors deeper in network behaviour or failures in the order of their frequency the program, and are invalid enough to expose corner cases of occurence are the following: that have not been dealt with properly. For a network, 1) Software bugs: code errors, bugs, etc., 2) Hardware fail- this corresponds to checking its behavior not only with the ures or bugs: bit errors or bitflips, switch failures, etc., 3) At- expected production traffic but with unexpected or abnormal tacks and external causes: compromised security, DoS/DDos, packets [39]. However, in networking, what is expected or etc., and 4) Misconfigurations: ACL /protocol misconfigs, etc. unexpected depends not only on the input (ingress) port but In SDNs, the above causes still exist and are persis- also the topology till the exit (egress) port and configuration tent [2]–[4], [12]–[16], [40]–[42]. We, however, realized that i.e., rules on the switches. Thus, there is a huge state the symptoms [1] of the above causes can manifest either space to explore. Relying only on production traffic is not as functional or performance-based problems on the data sufficient because production traffic may or may not trigger plane. To clarify further, the symptoms are either functional inconsistencies. However, having faults that can be triggered (reachability, security policy correctness, forwarding loops, at any point in time, due to a change in production traffic e.g., broadcast/multicast storms) or performance-based (Router malicious or accidental, is undesirable for a stable network. CPU high utilization, congestion, latency/throughput, inter- Thus, we need fuzz testing for checking network consistency. mittent connectivity). To abstract the analysis, if we disregard Accordingly, this paper introduces PAZZ which combines the performance-based symptoms, we realize the functional such capabilities with previous approaches to verify SDNs problems can be reduced to the verification of network against persistent data plane faults. Therefore, similar to correctness. Making the situation worse, the faults manifest program testing we ask: “How far to go with consistency in the form of inconsistency where the expected network state checks?” at control plane is different to the actual data plane state. Our Contributions: A physical network or network data plane comprises of devices and links. In SDNs, such devices are SDN switches • We identify and categorize the causes and symptoms connected through links. The data plane of the SDNs is all of data plane faults which are currently unaddressed about the network behaviour when subjected to input in the to provide some useful insights into the limitations of form of traffic. Just like in programs, we need different test existing approaches by investigating their frequency of cases as inputs with different coverage to test the code cov- occurence. Based on our insights, we make a case for erage. Similarly, in order to dynamically test the network be- fuzz testing mechanism for campus and private datacenter haviour thoroughly, we need input in the form of traffic with SDNs (§II); different coverage [43]. Historically, the network correctness or functional verification on the data plane has been either a • We introduce a novel methodology, PAZZ which detects path-based verification (network-wide) [20], [22]–[26], [44] and later, localizes faults by comparing control vs.
Recommended publications
  • Top 10 Cyber Crime Prevention Tips
    Top 10 Cyber Crime Prevention Tips 1. Use Strong Passwords Use different user ID / password combinations for different accounts and avoid writing them down. Make the passwords more complicated by combining letters, numbers, special characters (minimum 10 characters in total) and change them on a regular basis. 2. Secure your computer o Activate your firewall Firewalls are the first line of cyber defense; they block connections to unknown or bogus sites and will keep out some types of viruses and hackers. o Use anti-virus/malware software Prevent viruses from infecting your computer by installing and regularly updating anti-virus software. o Block spyware attacks Prevent spyware from infiltrating your computer by installing and updating anti- spyware software. 3. Be Social-Media Savvy Make sure your social networking profiles (e.g. Facebook, Twitter, Youtube, MSN, etc.) are set to private. Check your security settings. Be careful what information you post online. Once it is on the Internet, it is there forever! 4. Secure your Mobile Devices Be aware that your mobile device is vulnerable to viruses and hackers. Download applications from trusted sources. 5. Install the latest operating system updates Keep your applications and operating system (e.g. Windows, Mac, Linux) current with the latest system updates. Turn on automatic updates to prevent potential attacks on older software. 6. Protect your Data Use encryption for your most sensitive files such as tax returns or financial records, make regular back-ups of all your important data, and store it in another location. 7. Secure your wireless network Wi-Fi (wireless) networks at home are vulnerable to intrusion if they are not properly secured.
    [Show full text]
  • Trojans and Malware on the Internet an Update
    Attitude Adjustment: Trojans and Malware on the Internet An Update Sarah Gordon and David Chess IBM Thomas J. Watson Research Center Yorktown Heights, NY Abstract This paper continues our examination of Trojan horses on the Internet; their prevalence, technical structure and impact. It explores the type and scope of threats encountered on the Internet - throughout history until today. It examines user attitudes and considers ways in which those attitudes can actively affect your organization’s vulnerability to Trojanizations of various types. It discusses the status of hostile active content on the Internet, including threats from Java and ActiveX, and re-examines the impact of these types of threats to Internet users in the real world. Observations related to the role of the antivirus industry in solving the problem are considered. Throughout the paper, technical and policy based strategies for minimizing the risk of damage from various types of Trojan horses on the Internet are presented This paper represents an update and summary of our research from Where There's Smoke There's Mirrors: The Truth About Trojan Horses on the Internet, presented at the Eighth International Virus Bulletin Conference in Munich Germany, October 1998, and Attitude Adjustment: Trojans and Malware on the Internet, presented at the European Institute for Computer Antivirus Research in Aalborg, Denmark, March 1999. Significant portions of those works are included here in original form. Descriptors: fidonet, internet, password stealing trojan, trojanized system, trojanized application, user behavior, java, activex, security policy, trojan horse, computer virus Attitude Adjustment: Trojans and Malware on the Internet Trojans On the Internet… Ever since the city of Troy was sacked by way of the apparently innocuous but ultimately deadly Trojan horse, the term has been used to talk about something that appears to be beneficial, but which hides an attack within.
    [Show full text]
  • Civilians in Cyberwarfare: Conscripts
    Civilians in Cyberwarfare: Conscripts Susan W. Brenner* with Leo L. Clarke** ABSTRACT Civilian-owned and -operated entities will almost certainly be a target in cyberwarfare because cyberattackers are likely to be more focused on undermining the viability of the targeted state than on invading its territory. Cyberattackers will probably target military computer systems, at least to some extent, but in a departure from traditional warfare, they will also target companies that operate aspects of the victim nation’s infrastructure. Cyberwarfare, in other words, will penetrate the territorial borders of the attacked state and target high-value civilian businesses. Nation-states will therefore need to integrate the civilian employees of these (and perhaps other) companies into their cyberwarfare response structures if a state is to be able to respond effectively to cyberattacks. While many companies may voluntarily elect to participate in such an effort, others may decline to do so, which creates a need, in effect, to conscript companies for this purpose. This Article explores how the U.S. government can go about compelling civilian cooperation in cyberwarfare without violating constitutional guarantees and limitations on the power of the Legislature and the Executive. * NCR Distinguished Professor of Law and Technology, University of Dayton School of Law. ** Associate, Drew, Cooper & Anding, P.C., Grand Rapids, Michigan. 1011 1012 Vanderbilt Journal of Transnational Law [Vol. 43:1011 TABLE OF CONTENTS I. INTRODUCTION .............................................................
    [Show full text]
  • Cyber War and Deterrence Applying a General Theoretical Framework
    Cyber War and Deterrence Applying a General Theoretical Framework Capt Isaac Nacita, USAF Lt Col Mark Reith, USAF, PhD Disclaimer: The views and opinions expressed or implied in the Journal are those of the authors and should not be con- strued as carrying the official sanction of the Department of Defense, Air Force, Air Education and Training Command, Air University, or other agencies or departments of the US government. This article may be reproduced in whole or in part without permission. If it is reproduced, the Air and Space Power Journal requests a courtesy line. Introduction Military history, when superficially studied, will furnish arguments in support of any theory or opinion. —Paul Bronsart von Schellendorf In September 1870, after just six weeks of what many thought would be a pro- longed war, Prussian bystanders jeered Louis-Napoléon Bonaparte as he was carried to captivity in what is now Kassel, Germany. It was a fitting portrait of French na- tional disgrace.1 Their military structures before the war and lack of strategic plan- ning were partly to blame. National archivist Dallas D. Irvine points out, “it (the French system) was almost completely effective in excluding the army’s brain power from the staff and high command. To the resulting lack of intelligence at the top can be ascribed all the inexcusable defects of French military policy.”2 Never- theless, influenced by the idea that France had lost due to its lack of morale that an offensive approach would have provided, the military regrouped and refocused it- self, this time adopting “attaque á outrance.” This doctrine was French military strategy entering World War I, and it was almost immediately proved spectacularly wrong.
    [Show full text]
  • Study on Computer Trojan Horse Virus and Its Prevention ZHU Zhenfang
    International Journal of Engineering and Applied Sciences (IJEAS) ISSN: 2394-3661, Volume-2, Issue-8, August 2015 Study on Computer Trojan Horse Virus and Its Prevention ZHU Zhenfang to steal or viciously revise files, spy system information, steal various commands and passwords, and even format users’ Abstract— In recent years, the fast development of computer hardware. In addition, Trojan horse virus usually records network technology, has become an integral part of human’s life, keyboard operation by means of keyboard record, and then work and study. But with the popularity of the Internet, obtains the account and password of E-bank. Attackers can computer viruses, Trojans and other new terms have become some well-known network vocabularies. Studies have shown directly steal users’ wealth by obtaining accounts and that most users of computer are more or less suffered from passwords. On the other hand, Trojan horse can also cause the computer virus. So people must attach great importance to the native machine be affected by other vicious virus. network security problem. The paper studied Trojan virus. Paper first introduced the concept, characteristics and PREVENTION OF HORSE VIRUS categories of the Trojan virus and its harm, and then focused on the way and means of the Trojan’s spread. It introduced the According to the above introduction, we know that Trojan virus loading and hiding technology, too. Its last part Trojan horse virus is very dangerous. If we neglect the focused on the prevention measures, it put forward reasonable prevention, our computer may be easily attacked. For the suggestions to users, and paper also put forward prevention prevention of Trojan intrusion, Trojan intrusion should be advice to improve network security.
    [Show full text]
  • A Model of Stateful Firewalls and Its Properties
    A Model of Stateful Firewalls and its Properties Mohamed G. Gouda and Alex X. Liu1 Department of Computer Sciences, The University of Texas at Austin, Austin, Texas 78712-1188, U.S.A. Email: {gouda, alex}@cs.utexas.edu Abstract deployed in most businesses and institutions for securing private networks. A firewall is placed at the point of entry We propose the first model of stateful firewalls. In this between a private network and the outside Internet so that model, each stateful firewall has a variable set called the all incoming and outgoing packets have to pass through it. state of the firewall, which is used to store some packets The function of a firewall is to map each incoming or out- that the firewall has accepted previously and needs to re- going packet to one of a set of predefined decisions, such as member in the near future. Each stateful firewall consists of accept or discard. Based on how a decision is made for ev- two sections: a stateful section and a stateless section. Upon ery packet, firewalls are categorized into stateless firewalls receiving a packet, the firewall processes it in two steps. In and stateful firewalls. If a firewall decides the fate of every the first step, the firewall augments the packet with an ad- packet solely by examining the packet itself, then the fire- ditional field called the tag, and uses the stateful section to wall is called a stateless firewall. If a firewall decides the compute the value of this field according to the current state fate of some packets not only by examining the packet it- of the firewall.
    [Show full text]
  • Stateful Firewalls
    05 7376 ch03 2/11/05 2:14 PM Page 55 3 Stateful Firewalls THE FOCUS OF THIS CHAPTER IS ON STATEFUL firewalls, a type of firewall that attempts to track the state of network connections when filtering packets.The stateful firewall’s capabilities are somewhat of a cross between the functions of a packet filter and the additional application-level protocol intelligence of a proxy. Because of this additional protocol knowledge, many of the problems encountered when trying to configure a packet-filtering firewall for protocols that behave in nonstandard ways (as mentioned in Chapter 2,“Packet Filtering”) are bypassed. This chapter discusses stateful filtering, stateful inspection, and deep packet inspection, as well as state when dealing with various transport and application-level protocols.We also demonstrate some practical examples of how several vendors implement state track- ing as well as go over examples of such firewalls. How a Stateful Firewall Works The stateful firewall spends most of its cycles examining packet information in Layer 4 (transport) and lower. However, it also offers more advanced inspection capabilities by targeting vital packets for Layer 7 (application) examination, such as the packet that ini- tializes a connection. If the inspected packet matches an existing firewall rule that per- mits it, the packet is passed and an entry is added to the state table. From that point forward, because the packets in that particular communication session match an existing state table entry, they are allowed access without call for further application layer inspec- tion.Those packets only need to have their Layer 3 and 4 information (IP address and TCP/UDP port number) verified against the information stored in the state table to confirm that they are indeed part of the current exchange.This method increases overall firewall performance (versus proxy-type systems, which examine all packets) because only initiating packets need to be unencapsulated the whole way to the application layer.
    [Show full text]
  • Best Practices: Use of Web Application Firewalls
    OWASP Papers Program Best Practice: Use of Web Application Firewalls Best Practices: Use of Web Application Firewalls Version 1.0.5, March 2008, English translation 25. May 2008 Author: OWASP German Chapter with collaboration from: Maximilian Dermann Mirko Dziadzka Boris Hemkemeier Achim Hoffmann Alexander Meisel Matthias Rohr Thomas Schreiber OWASP Papers Program Best Practice: Use of Web Application Firewalls Abstract Web applications of all kinds, whether online shops or partner portals, have in recent years increasingly become the target of hacker attacks. The attackers are using methods which are specifically aimed at exploiting potential weak spots in the web application software itself – and this is why they are not detected, or are not detected with sufficient accuracy, by traditional IT security systems such as network firewalls or IDS/IPS systems. OWASP develops tools and best practices to support developers, project managers and security testers in the development and operation of secure web applications. Additional protection against attacks, in particular for already productive web applications, is offered by what is still a emerging category of IT security systems, known as Web Application Firewalls (hereinafter referred to simply as WAF), often also called Web Application Shields or Web Application Security Filters. One of the criteria for meeting the security standard of the credit card industry currently in force (PCI DSS - Payment Card Industry Data Security Standard v.1.1) for example, is either a regular source code review or the use of a WAF. The document is aimed primarily at technical decision-makers, especially those responsible for operations and security as well as application owners (specialist department, technical application managers) evaluating the use of a WAF.
    [Show full text]
  • Automatic Discovery of Evasion Vulnerabilities Using Targeted Protocol Fuzzing
    Automatic Discovery of Evasion Vulnerabilities Using Targeted Protocol Fuzzing Antti Levomäki Olli-Pekka Niemi Christian Jalio Forcepoint Forcepoint Forcepoint Helsinki, Finland Helsinki, Finland Helsinki, Finland [email protected] [email protected] [email protected] Abstract— Network protocol normalization and reassembly is Our goal is to find protocol reassembly problems in the basis of traffic inspection performed by NGFW and IPS middlebox traffic inspection. Most middlebox security devices. Even common network protocols are complex with products are proprietary solutions with no visibility into the multiple possible interpretations for the same traffic sequence. actual inspection process. The inspection behaviour also We present a novel method for automated discovery of errors in changes with signature updates, inspection policy changes and traffic normalization by targeted protocol stack fuzzing. These software upgrades. The inspection process is therefore a black errors can be used by attackers to evade detection and bypass box for testing purposes. security devices. The search space for different ways to send a network Keywords—network; intrusion prevention; evasion; fuzzing; exploit is large. The traffic for a relatively simple HTTP GET IDS; IPS; NGFW request is composed following at least the following specifications: I. INTRODUCTION •RFC 2616 – Hypertext Transfer Protocol HTTP/1.1 [3]. Network security devices perform real-time analysis on •RFC 793 - Transmission Control Protocol [4]. network traffic to detect malicious or unwanted traffic. •RFC 791 – Internet Protocol [5]. Intrusion prevention systems (IPS) and next generation firewalls (NGFW) are common examples of middlebox Many protocols also have commonly implemented systems that can alert and possibly terminate offending traffic. extensions increasing the complexity.
    [Show full text]
  • Guidelines on Firewalls and Firewall Policy
    Special Publication 800-41 Revision 1 Guidelines on Firewalls and Firewall Policy Recommendations of the National Institute of Standards and Technology Karen Scarfone Paul Hoffman NIST Special Publication 800-41 Guidelines on Firewalls and Firewall Revision 1 Policy Recommendations of the National Institute of Standards and Technology Karen Scarfone Paul Hoffman C O M P U T E R S E C U R I T Y Computer Security Division Information Technology Laboratory National Institute of Standards and Technology Gaithersburg, MD 20899-8930 September 2009 U.S. Department of Commerce Gary Locke, Secretary National Institute of Standards and Technology Patrick D. Gallagher, Deputy Director GUIDELINES ON FIREWALLS AND FIREWALL POLICY Reports on Computer Systems Technology The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology (NIST) promotes the U.S. economy and public welfare by providing technical leadership for the nation’s measurement and standards infrastructure. ITL develops tests, test methods, reference data, proof of concept implementations, and technical analysis to advance the development and productive use of information technology. ITL’s responsibilities include the development of technical, physical, administrative, and management standards and guidelines for the cost-effective security and privacy of sensitive unclassified information in Federal computer systems. This Special Publication 800-series reports on ITL’s research, guidance, and outreach efforts in computer security and its collaborative activities with industry, government, and academic organizations. National Institute of Standards and Technology Special Publication 800-41 Revision 1 Natl. Inst. Stand. Technol. Spec. Publ. 800-41 rev1, 48 pages (Sep. 2009) Certain commercial entities, equipment, or materials may be identified in this document in order to describe an experimental procedure or concept adequately.
    [Show full text]
  • Informational Supplement Best Practices on Spyware Prevention and Detection the Internet Has Become a Popular Method for Both C
    Informational Supplement Best Practices on Spyware Prevention and Detection The Internet has become a popular method for both conducting business and managing finances through online banking relationships. While most financial institutions and some individuals have taken steps to protect their computers, many firewall and anti-virus software packages do not protect computers from one of the latest threats, “spyware” – a form of software that collects personal and confidential information about a person or organization without their proper knowledge or informed consent, and reports it to a third party. This informational supplement describes the various challenges and best practices related to spyware. Financial institutions should consider these recommendations to prevent and detect spyware on both bank-owned and customer computers. Spyware Infection Spyware is usually installed without a user’s knowledge or permission. However, users may intentionally install spyware without understanding the full ramifications of their actions. A user may be required to accept an End User Licensing Agreement (EULA), which often does not clearly inform the user about the extent or manner in which information is collected. In such cases, the software is installed without the user’s “informed consent.” Spyware can be installed through the following methods: • Downloaded with other Internet downloads in a practice called “bundling.” In many cases, all the licensing agreements may be included in one pop-up window that, unless read carefully, may leave the user unaware of “bundled” spyware. • Directly downloaded by users who were persuaded that the technology offers a benefit. Some spyware claims to offer increased productivity, virus scanning capabilities or other benefits.
    [Show full text]
  • Security Awareness Newsletter for Security Aware People News
    SecuritytheAwareness security awareness newsletter for security aware people News The Human Firewall Manifesto The 5 Principles of Being a Human Firewall Proactive Security Awareness How Human Firewalls Stop Cybercrime © 2021 The Security Awareness Company - KnowBe4, Inc. All rights reserved. Company - KnowBe4, Inc. Awareness The Security © 2021 The 5 Principles of Being a Human Firewall The concept behind the human firewall was built on the most critical aspect of security: people. When we talk about preventing data breaches and other incidents, we’re talking about protecting people, not computers. It’s easy to view data as some faceless, lifeless asset that resides on hard drives and servers. In reality, every bit of that data represents a person. Data equals someone’s identity—their digital DNA. And it’s not computers trying to steal those identities. It’s evil people. That’s why we need good human firewalls who remain vigilant in the fight against cybercrime. It’s the human firewall’s job to prioritize security in every facet of life and make the world a better place for everyone. How do you do that? By living and working according to these five security awareness principles: 1. Never make assumptions. Don’t draw your own conclusions. If you’re unsure of something, reach out. Ask. For example, if you find a USB flash drive, don’t assume someone lost it by accident. Turn that flash drive in to management so it can be analyzed for malicious software. 2. Stay alert. Situational awareness is the human firewall’s best friend. Keep your guard up.
    [Show full text]