Information Security

A constant work in progress. Share and edit to make this map as complete as possible. Add examples, information, etc.

Get Started. It's Free
or sign up with your email address
Rocket clouds
Information Security by Mind Map: Information Security

1. Security attacks

1.1. Passive

1.1.1. Message interception and transmission analysis

1.1.1.1. Hard to detect

1.2. Active

1.2.1. Message modification

1.2.1.1. Purposefully modifying intercepted messages

1.2.2. Retransmission

1.2.2.1. Transmission of information previously intercepted

1.2.3. Mascarading

1.2.3.1. Pretending false identities

1.2.4. Denial of Service (DDOS)

1.2.4.1. overloading capacity of a service thus slowing or disabling it. Not so much an access attempt but a way to hinder system operation

1.2.4.1.1. Smurf

1.2.4.1.2. SYN Flood

1.2.4.1.3. Ping of death

1.2.4.1.4. Mail bombs, etc

1.2.5. Exploitation of system vulnerabilities

1.2.6. Crypto attacks

2. Security services

2.1. Authenticity

2.1.1. Achieved by authentication (there are 3 types)

2.1.1.1. Something you know

2.1.1.1.1. Password

2.1.1.1.2. Pin

2.1.1.1.3. Mother's maiden name

2.1.1.1.4. Passcode

2.1.1.1.5. Fraternity

2.1.1.1.6. Chant, etc

2.1.1.2. Something you have

2.1.1.2.1. ATM Card

2.1.1.2.2. Smart Card

2.1.1.2.3. Token

2.1.1.2.4. Key

2.1.1.2.5. ID Badge

2.1.1.2.6. Drivers License

2.1.1.2.7. Passpoert

2.1.1.3. Something you are

2.1.1.3.1. Fingerprint

2.1.1.3.2. Voice scan

2.1.1.3.3. Iris Scan

2.1.1.3.4. DNA

2.1.2. Multi factor authentication

2.1.2.1. Consists of a combination of 2-3 forms of authentication (listed above)

2.1.3. Single sign-on

2.1.3.1. A concept where the user has one universal strong password. For more information, look into the following:

2.1.3.1.1. Kerberos

2.1.3.1.2. CA-Unicenter

2.1.3.1.3. Memco Proxima

2.1.3.1.4. Intellisoft SnareWorks

2.1.3.1.5. Tivoli Global Sign-on

2.1.3.1.6. x.509

2.2. Non repudiation

2.2.1. Not allowing a subject to deny the actions performed

2.2.1.1. By challenging the authenticity of the signature

2.2.1.1.1. e-mail security

2.3. Access control

2.4. Confidentiality

2.4.1. Gaining unauthorized access to sensitive information.

2.4.1.1. Can be done by a person, program or computer

2.5. Integrity

2.5.1. Gaining access and tampering with a system resource. Also by inserting additional objects in the system.

2.6. Availability

2.6.1. Destroying assets within the system, rendering them unavailable or unusable

2.7. Confidentiality, Integrity and Availability are called The Big Three

3. Security mechanisms

3.1. Encryption

3.1.1. Makes information unreadable without a specific password

3.2. Digital Signature

3.2.1. Certifies the user's identity

3.2.1.1. add more here

3.3. Access Control

3.3.1. Access rights list

3.3.2. Passwords

3.3.3. Security tags

3.3.4. Access duration

3.3.5. The way, time and attempts of access

3.4. Data integrity

3.4.1. Checking through parity bits, hashes, etc.

3.5. Exchange authenticity

3.5.1. Passwords

3.5.2. Signatures

3.5.3. Encryption

3.6. Fill with traffic

3.6.1. Misleading any intercepting by filling the communication fake traffic and destinations

3.7. Routing control

3.7.1. Selecting a safe(r) route of communication

3.8. Journalling

3.8.1. Keeping records of ins and outs

4. Security models

4.1. Discretionary access control

4.1.1. The owner decides how to protect and share his own data

4.1.1.1. Capability systems are sometimes described as providing discretionary controls because they permit subjects(owners) to transfer their access to other subjects

4.1.1.1.1. also see the Confused Deputy problem

4.2. Mandatory access control

4.2.1. The system decides how the data is shared

4.2.2. Used in systems where security is critical (the military)

4.2.2.1. Generally more secure than DAC

4.2.2.2. Harder to implement and configure

4.2.2.3. Relies on the system to control access

4.2.2.4. Is slow, leading to low work performance

4.2.3. Assigns sensitivity levels (labels)

4.2.4. Every object is given a sensitivity level and it's only accessible to users who are cleared UP TO that particular level

4.2.4.1. Example: If a file is classified as confidential, MAC will prevent from writing secret or top secret into that file (confidential<secret<topsecret)

4.2.5. Only administrators make changes to an object's level, not even the object's owners can't

4.3. Access control matrix

4.3.1. A matrix characterizing the rights of subjects in respect to objects in a system

4.4. Access control list

4.4.1. A list of rights for each subject attached to the object

4.4.1.1. Basically a file used by the access control system to determine who may access what programs and files, in what method and at what time. It differs from OS to OS

4.4.1.1.1. Type of access (also used in the rest of the mind map)

4.5. Capabilities list

4.5.1. A privileged data structure containing objects and their access rights

4.5.1.1. Practically: Proof of right to an object is done by matching: the index of a file descriptor from within the process - with the file descriptor table in the kernel, to allow access to said kernel object.

4.6. Multi level security

4.6.1. Inspired from military model

4.6.1.1. Public < Restricted < Confidential < Top Secret

4.7. Bell - LaPadula

4.7.1. Only ensures confidentiality using 2 main rules

4.7.1.1. NO READ UP

4.7.1.2. NO WRITE DOWN

4.7.2. Based on three properties

4.7.2.1. Simple security property - A subject at a given security level may not read an object at a higher security level.

4.7.2.1.1. Users may view content only at or below their own security level.

4.7.2.2. The star property - A subject at a given security level must not write to any object at a lower security level

4.7.2.2.1. Writing an object at a lower security level means transferring information from high to lower sensitivity. Lowering security level is possible in Bell LaPadula through the concept of Trusted Subjects

4.7.2.2.2. The Strong Star Property is an alternative to star property. It only allows writing on the same level.

4.7.2.3. The discretionary security property - use of an access matrix to specify the discretionary access control.

4.7.3. Tranquility principle

4.7.3.1. It states that neither subject nor object can change their classification while being referenced. There are two forms: strong, weak.

4.7.3.1.1. Strong tranquility

4.7.3.1.2. Weak tranquility

4.8. Biba

4.8.1. Only ensures integrity using 2 main rules

4.8.1.1. NO READ DOWN

4.8.1.2. NO WRITE UP

4.8.2. Developed as a response to Bell LaPadula (BLP) assessing the integrity weakness. It uses subjects and objects ordered under levels of integrity.

4.8.2.1. Preserving data integrity has three goals

4.8.2.1.1. Prevent data modification by unauthorised parties

4.8.2.1.2. Prevent unauthorized modifications by authorised parties

4.8.2.1.3. Maintain internal and external consistency

4.8.2.2. Based on three properties, similar to BLP (just reversed)

4.8.2.2.1. The Simple Integrity Axiom

4.8.2.2.2. The Star Integrity Axiom

4.8.2.2.3. Invocation Property

4.9. Clark - Wilson

4.9.1. Only ensures integrity (like Biba) and addresses all 3 integrity goals

4.9.1.1. Prevents unauthorized users from making modifications

4.9.1.2. Maintains internal and external consistency

4.9.1.3. Prevents authorized users from making improper modifications

4.9.2. The model enforces integrity using data items and processes

4.9.2.1. At its core it's based on the notion of transactions

4.9.2.1.1. A well-formed transaction is a series of operations that transition a system from one consistent state to another consistent state.

4.9.2.1.2. In this model the integrity policy addresses the integrity of the transactions.

4.9.2.1.3. The principle of separation of duty requires that the certifier of a transaction and the implementer be different entities.

4.9.3. Ensures integrity with 2 sets of rules Certification Rules (C) and Enforcement Rules (E): a total of 9 rules as follows:

4.9.3.1. C1—When an IVP is executed, it must ensure the CDIs are valid.

4.9.3.2. C2—For some associated set of CDIs, a TP must transform those CDIs from one valid state to another.

4.9.3.3. Since we must make sure that these TPs are certified to operate on a particular CDI, we must have E1 and E2.

4.9.3.4. E1—System must maintain a list of certified relations and ensure only TPs certified to run on a CDI change that CDI.

4.9.3.5. E2—System must associate a user with each TP and set of CDIs. The TP may access the CDI on behalf of the user if it is “legal.”

4.9.3.6. This requires keeping track of triples (user, TP, {CDIs}) called “allowed relations.”

4.9.3.7. C3—Allowed relations must meet the requirements of “separation of duty.”

4.9.3.8. We need authentication to keep track of this.

4.9.3.9. E3—System must authenticate every user attempting a TP. Note that this is per TP request, not per login.

4.9.3.10. For security purposes, a log should be kept.

4.9.3.11. C4—All TPs must append to a log enough information to reconstruct the operation.

4.9.3.12. When information enters the system it need not be trusted or constrained (i.e. can be a UDI). We must deal with this appropriately.

4.9.3.13. C5—Any TP that takes a UDI as input may only perform valid transactions for all possible values of the UDI. The TP will either accept (convert to CDI) or reject the UDI.

4.9.3.14. Finally, to prevent people from gaining access by changing qualifications of a TP:

4.9.3.15. E4—Only the certifier of a TP may change the list of entities associated with that TP.

4.10. Problems with formal models (Bell-LaPadula, Biba, Clark Wilson)

4.10.1. Based on static infrastructure

4.10.2. Defined and succint poicies

4.10.3. They don't work incorporate systems which are dynamic by nature

4.10.4. They don't deal with elements such as

4.10.4.1. Viruses / active content

4.10.4.2. Trojan Horses

4.10.4.3. Firewalls

4.10.5. They have limited documentation on how to build these systems

4.11. Orange book

4.11.1. Provides the information needed to classify systems (A,B,C,D) by defining the level of trust that may be placed on them

4.11.1.1. A - Verified protection

4.11.1.1.1. A1

4.11.1.2. B - MAC

4.11.1.2.1. B1

4.11.1.2.2. B2

4.11.1.2.3. B3

4.11.1.3. C - DAC

4.11.1.3.1. C1

4.11.1.3.2. C2

4.11.1.4. D - Minimal security. Systems that failed evaluation

4.11.2. Systems take a long time to certify and certification is expensive. Any changes to the system (updates, patches, service packs) BREAK the certification

4.11.3. Based on Bell LaPadula, not used outside of the government sector

4.11.3.1. Therefore it is not used in client-server scenarios or corporate computing

4.11.3.2. Stand alone, NOT for network use

4.11.3.2.1. Red Book is an extension of Orange Book used for networks.

5. Security of Distributed Systems

5.1. Steps for building a secure system

5.1.1. 1.Specifying the requirements and security policies

5.1.1.1. The actions allowed for each entity (user, service, machine, process...)

5.1.1.1.1. e.g. Globus

5.1.2. 2.Choosing security mechanisms

5.1.2.1. Focusing on global operation

5.1.2.1.1. e.g Globus

5.1.3. 3.Implementing (protocols and entities)

5.1.3.1. Trusted Computer Base

5.1.3.1.1. Totality of components: software and hardware mechanisms required to implement the security policy

5.1.3.1.2. Reduced Interfaces for Secure System Components (RISSC)

5.1.4. 4. Assuring proper functional mechanisms

5.1.4.1. Formal methods

5.1.4.1.1. Proper pecifying , designing, implementing at each step

5.1.4.2. According to standards

5.1.4.2.1. Implementing multiple levels of trust

5.1.4.2.2. Trusting that the security policy is ensured properly.

5.1.4.2.3. Information Technology security Evaluation Criteria ( ITSEC)

5.1.4.2.4. Trusted Computer System Evaluation Criteria - same as Orange BOOK (TCSEC)

5.1.4.2.5. Common Criteria - Common Criteria for Information Technology Security Evaluation

5.2. Authentication

5.2.1. RADIUS

5.2.1.1. Remote Authentication Dial In User Service (RADIUS)

5.2.1.1.1. The default standard for remote authentication

5.2.1.2. RADIUS Steps:

5.2.1.2.1. 1.The user enters the network through a modem

5.2.1.2.2. 2.RADIUS client asks for a username and passowrd

5.2.1.2.3. 3.RADIUS client sends an Access Request (code 1)

5.2.1.2.4. 4.RADIUS server authenticates the user and sends the Access Accept (code 2) or Access Reject (code 3) to the RADIUS client.

5.2.1.3. RADIUS steps detailed (client-server)

5.2.1.3.1. 1. Client Actions

5.2.1.3.2. 2. Server Actions

5.2.1.3.3. 3.Client Actions

5.2.2. Secure RPC

5.2.2.1. Developed by SUN for its OS

5.2.2.1.1. Based on a combination of public and secret keys

5.2.2.2. Each principal - (user/computer) has a pair of keys , both held in a database, along with the username

5.2.2.2.1. Public key - kept in clear

5.2.2.2.2. Secret key - encrypted with DES with principal's password

5.2.2.3. The principal (user/computer)

5.2.2.3.1. Verifies his identity by showing he can decrypt the secret key (which is DES encrypted)

5.2.2.3.2. Combines his secret key with the public key of his partner.

5.2.2.4. More:

5.2.2.4.1. Secure RPC in NFS

5.3. Access control

5.3.1. Uses two premises

5.3.1.1. Identifying the user

5.3.1.1.1. No one can steal someonelse's access rights

5.3.1.1.2. Ensured through authentication

5.3.1.2. Protecting the information about the access rights against unauthorized modifying

5.3.1.3. :"Does the subject S have the right to access the object O?"

5.3.2. Types :

5.3.2.1. DAC

5.3.2.1.1. see on the map somewhere

5.3.2.2. MAC

5.3.2.2.1. see on the map somewhere

5.3.2.3. Controls access

5.3.2.3.1. Access matrix

5.3.2.3.2. RBAC

5.3.2.4. Controls information flux

5.3.2.4.1. Multi-level Model

6. Security in the Local Area Network

6.1. Why target the LAN?

6.1.1. 99% of all ports are left open on LAN level

6.1.1.1. each port is a possible breach

6.1.1.1.1. in 2006, more than half of attacks came from within the network

6.1.2. Out of all the OSI layers, level 2 (data link) can prove to be very vulnerable

6.1.2.1. The data link layer is used for the encoding, decoding and logical organization of data bits. Data packets are framed and addressed by this layer, which has two sublayers.

6.1.2.1.1. MAC (Media Access Control)

6.1.2.1.2. LLC (Logical Link Control)

6.2. MAC flooding

6.2.1. what is it:

6.2.1.1. The attacker feeds the switch many ethernet frames, each containing different source MAC addresses with the intention of consuming the limited memory reserved for the MAC address table. The effect is to force legitimate MAC addresses out of the MAC address table, causing significant quantities of incoming frames to be flooded out on all ports.

6.2.2. programs used:

6.2.2.1. dsniff (C)

6.2.2.2. macoff (Perl)

6.2.3. how to protect from it:

6.2.3.1. limiting the maximum number of new learned MAC addresses

6.2.3.2. blocking the port in case of flooding

6.2.3.3. notifying the administration through a SNMP message

6.2.3.4. Port Security mechanism

6.2.3.4.1. Switches can be configured to limit the number of MAC addresses that can be learned on ports connected to end stations

6.2.3.4.2. A smaller table of "secure" MAC addresses is maintained in addition to (and as a subset to) the traditional "MAC address table."

6.2.3.5. MAC filtering

6.2.3.5.1. MAC addresses to be authenticated against an authentication, authorization and accounting (AAA) server and subsequently filtered

6.3. DHCP Starvation

6.3.1. what is it:

6.3.1.1. The attacker broadcasts DHCP requests with spoofed MAC addresses, thus causing the network to exhaust the address space available to the DHCP servers for a period of time. Network attackers can then set up a rogue DHCP server on their system and respond to new DHCP requests from clients on the network.

6.3.1.1.1. By placing a rogue DHCP server on the network, a network attacker can provide clients with addresses and other network information. Because DHCP responses typically include default gateway and Domain Name System (DNS) server information, network attackers can supply their own system as the default gateway and DNS server resulting in a man-in-the-middle attack

6.3.1.1.2. A rogue DHCP server is a DHCP server set up on a network by an attacker.

6.3.2. programs used:

6.3.2.1. the gobler

6.3.2.2. DHCP Starv

6.3.2.3. scapy

6.3.2.4. yersinia

6.3.3. how to protect from it:

6.3.3.1. Port security mechanism

6.3.3.1.1. restricts the maximum number of mac addresses accepted through a port

6.3.3.2. DHCP Snooping Mechanism

6.3.3.2.1. the switch marks all ports except the one going to the DHCP server as "Untrusted"

6.3.3.2.2. Only a whitelist of IP addresses may access the network. The whitelist is configured at the switch port level, and the DHCP server manages to access control. Only specific IP addresses with specific MAC addresses on specific ports may access the IP network.

6.4. ARP Spoofing

6.4.1. what is it:

6.4.1.1. The attacker exploits the ARP protocol by sending spoofed ARP messages onto the LAN to associate the attacker's MAC address with the IP address of a target host, so that any traffic meant for the target host will be sent to the attacker's MAC instead, making it easy to inspect the packets, and forward the traffic to the actual default gateway (intercepting traffic), modify the data before forwarding it (man-in-the-middle attack),launch a denial-of-service attack by causing some or all of the packets on the network to be dropped

6.4.1.2. ARP spoofing can occur while implementing redundancy of network services.

6.4.2. how to protect from it:

6.4.2.1. Static ARP entries

6.4.2.1.1. ARP reply packets are ignored if the IP to MAC mappings in the local ARP cache can be statically entered. (fixed)

6.4.2.2. ARP spoofing detecion software

6.4.2.2.1. In a more passive approach a device listens for ARP replies on a network, and sends a notification via email when an ARP entry changes

6.4.2.2.2. Software that detects ARP spoofing relies on cross-checking and certifying the ARP responses. Any uncertified ARP response can then be blocked

6.4.2.3. programs like :

6.4.2.3.1. anti-arp

6.4.2.3.2. antidote

6.4.2.3.3. arp_antidote

6.4.2.3.4. ARPalert

6.4.2.3.5. ARPOn

6.4.2.3.6. ARPWatch

6.4.2.3.7. DefendARP

6.4.2.3.8. Prelude IDS

6.4.2.3.9. Snort

6.4.2.3.10. XARP

6.4.3. programs used:

6.4.3.1. ARPspoof

6.4.3.2. ARPoison

6.4.3.3. Subterfuge

6.4.3.4. dSploit

6.4.3.4.1. android (passive)

6.4.3.5. SwitchSniffer

6.4.3.6. Simsang

6.4.3.7. Cain

6.4.3.7.1. windows

6.4.3.8. Ettercap

6.4.3.9. dSniff

6.5. MAC spoofing

6.5.1. what is it:

6.5.1.1. Atacker sends packets using a spoofed MAC address

6.5.2. how to protect from itL

6.5.2.1. DHCP snooping

6.5.2.1.1. see above

6.6. IP spoofing

6.6.1. what is it:

6.6.1.1. Attacker sends packets using spoofed MAC address

6.6.2. how to protect from it:

6.6.2.1. IP Source Guard mechanism

6.6.2.1.1. uses the information from the DHCP table

6.7. Spanning tree attack

6.7.1. STP protocol

6.7.1.1. Basically, STP prevents bridge loops and the broadcast radiation that results from them

6.7.2. what is it:

6.7.2.1. Attacker sends spoofed BPDU messages in attempt to become ROOT. Afterwards, the attacker intercepts data transfers between switches.

6.7.2.1.1. BPDU (Bridge Protocol Data Unit) is a STP specific frame, used to keep the network loop free, by reporting multiple paths between switches and closing the ports allowing loops to happen

6.7.3. how to protect from it:

6.7.3.1. BPDU Guard

6.7.4. programs used:

6.7.4.1. Yersinia

6.8. VLAN Hopping

6.8.1. attacks is for an attacking host on a VLAN to gain access to traffic

6.8.1.1. Double tagging

6.8.1.2. Switch spoofing