Casio fx-50FH II

  1. Contents
  2. References
Casio fx-50FH II

NGFW – research (6Nov2017)

  1. Requirements – Summary
  2. Requirements – Detailed
  3. References
    1. Magic Quadrant for Enterprise Network Firewalls 2017.
    2. Security value map of NGFW.
  4. Follow-ups
    1. Fortinet Demo (FortiGate 1500D).
      1. demo / demo
NGFW – research (6Nov2017)

Private: CC7174 – WK5 (4/11/17)

Aggregating Data Using Group Functions

  1. Contents – Summary
    1. Group Functions fundamentals
    2. Types of Group Functions
    3. GROUP BY clause
    4. HAVING clause
    5. NESTED Group Functions
  2. Contents – detailed
    1. Group Functions fundamentals
      1. return a single result row based on group of rows;
      2. appear in the SELECT list and in ORDER BY and HAVING clauses;
      3. Guidelines for using GROUP Functions
        1. data types for the functions with the expr argument may be CHAR, VARCHAR2, NUMBER or DATE;
        2. All group functions ignore NULL values. To substitute a value for NULL values use the NVL, NVL2 or COALESCE functions;
        3. Oracle server:
          1. implicitly sorts the result set in ascending order when using a GROUP BY clause;
          2. Use ORDER BY clause if the need arises to sort the data in descending order;
    2. Types of Group Functions
      1. appear in the SELECT or the HAVING clause of the SELECT statement;
      2. Requires a GROUP BY clause for grouping a result set;
      3. Group functions cannot appear in WHERE clause;
      4. Aggregate functions 
        1. AVG([DISTINCT | ALL] n)
        2. COUNT ({*|[DISTINCT | ALL] expr})
        3. MAX ([DISTINCT | ALL] expr)
        4. MIN ([DISTINCT | ALL] expr)
        5. STDDEV ([DISTINCT | ALL] expr)
        6. SUM ([DISTINCT | ALL] n)
        7. VARIANCE ([DISTINCT | ALL] x)
        8. COUNT(DISTINCT P_Code)…
    3. GROUP BY clause
      1. divide the rows in a table into smaller groups;
      2. GROUP BY clause is used with the SELECT statement to make a group of rows based on the values of a specific column or expression;
        1. Guidelines for using Group by:
          1. use WHERE clause to restrict rows before they are divided into groups;
          2. Columns must be included in the GROUP BY clause;
          3. No column alias can be used in the GROUP BY clause;
        2. GROUP BY clause on Multiple Columns:
          1. SELECT Paperback, Type, COUNT(Title) AS   “Total Books”  FROM Books GROUP BY Paperback, Type;
    4. HAVING clause
      1. specifies a search condition for a group or an aggregate;
      2. HAVING is usually used in a GROUP BY clause, but even if you are not using GROUP BY clause, you can use HAVING to function like a WHERE clause;
      3. Oracle’s step when performs the HAVING clause:
        1. Rows are grouped
        2. The group function is applied to the group
        3. Only the groups that match the criteria in the HAVING clause are displayed;
          1. SELECT Paperback, Type, COUNT(Title) AS “Total Books” FROM Books GROUP BY Paperback, Type   HAVING COUNT(Title) > 2;
    5. NESTED Group Functions
      1. SELECT MAX(AVG(Price)) FROM Books GROUP BY P_Code;
  3. References
    1. Oracle Database Edition 11g Getting Started Guide.
    2. Tasks after created a database.
  4. Follow-ups
    1. Coursework assignment start every Sat
    2. Configure 11g XE and create database
      1. SQL Developer as an Alternative for Creating Database Users:

        If you have experience with SQL Developer, you can use it instead of the command line to create a database user, as follows:

        1. Create a database connection for the SYSTEM user.
        2. Open that database connection for the SYSTEM user.
        3. Right-click the Other Users node in the Connections navigator under that connection.
    3. Best Practices: Priority of Functions
Private: CC7174 – WK5 (4/11/17)

CC7173 – WK5 (31/10/17)

Android fragments and intents

  1. Contents summary
    1. Concepts of Android Fragments and Intent
    2. Learn how to use the Fragments and Intent in Android app development
  2. Contents detailed
    1. Concepts of Android Fragments and Intent
      1. Fragments
        1. piece of an activity (sub-activity) which enable more modular activity design;
          1. possible to work with same result by activity, but fragments will be more modular, such as split screen / contents in fragments at small screens;
        2. Important points about fragment:
          1. contains own layout and its own behaviour with its own life cycle callbacks;
          2. add or remove fragments in an activity while the activity is running;
          3. can combine multiple fragments in a single activity to build a multi-plane UI;
          4. A fragment can be used in multiple activities;
          5. Fragment life cycle is closely related to the life cycle of its host activity which means when the activity is paused, all the fragments available in the activity will also be stopped;
          6. A fragment can implement a behaviour that has no user interface component;
          7. Fragments were added to the Android API in Honeycomb version of Android which API version 11;
        3. How to create a fragment
          1. by extending Fragment class;
          2. can insert a fragment into your activity layout by declaring the fragment in the activity’s layout file, as a <fragment> element;
        4. Methods which can be overridden in fragment class
          1. onAttach()
            1. fragment instance is associated with an activity instance; fragment and the activity is not fully initialized;
            2. Typically you get in this method a reference to the activity which uses the fragment for further initialization work;
          2. onCreate()
            1. calls this method when creating the fragment;
            2. should initialize essential components of the fragment that you want to retain when the fragment is paused or stopped, then resumed;
          3. onCreateView()
            1. calls this callback when it’s time for the fragment to draw its user interface for the first time;
            2. To draw a UI for your fragment, you must return a View component from this method that is the root of your fragment’s layout;
            3. return null if the fragment does not provide a UI;
          4. onActivityCreated()
            1. is called after the onCreateView() method when the host activity is created;
            2. At this point, view can be accessed with the findViewById() method. example. In this method you can instantiate objects which require a Context object
          5. onStart()
            1. is called once the fragment gets visible;
          6. onResume()
            1. Fragment becomes active;
          7. onPause()
            1. system calls this method as the first indication that the user is leaving the fragment;
            2. usually where you should commit any changes that should be persisted beyond the current user session;
          8. onStop()
            1. Fragment going to be stopped by calling onStop();
          9. onDestroyView()
            1. Fragment view will destroy after call this method;
          10. onDestroy()
            1. to do final clean up of the fragment’s state but Not guaranteed to be called by the Android platform;
        5. How to use Fragments?
          1. Decide how many fragments you want to use in an activity; for example, to use two fragments to handle landscape and portrait modes of the device;
          2. based on number of fragments, create classes which will extend the Fragment class; The Fragment class has above mentioned callback functions;
          3. Corresponding to each fragment, you will need to create layout files in XML file. These files will have layout for the defined fragments;
          4. Finally modify activity file to define the actual logic of replacing fragments based on your requirement;
        6. Sample codes of (2 fragments) pressing two buttons to change colors in background;
      2. Intent (message)
        1. What is Android Intent?
          1. an abstract description of an operation to be performed;
          2. can be used with startActivity to launch an Activity,
          3. broadcastIntent to send it to any interested BroadcastReceiver components,
          4. startService(Intent) or bindService(Intent, ServiceConnection, int) to communicate with a background Service;
        2. How to use intent
          1. an Activity that needs to launch an email client and sends an email using your Android device
          2. Activity would send an ACTION_SEND along with appropriate chooser, to the Android Intent Resolver;
          3. The specified chooser gives the proper interface for the user to pick how to send your email data (Sample 1):Intent email = new Intent(Intent.ACTION_SEND, Uri.parse(“mailto:”)); email.putExtra(Intent.EXTRA_EMAIL, recipients); email.putExtra(Intent.EXTRA_SUBJECT, subject.getText().toString()); email.putExtra(Intent.EXTRA_TEXT, body.getText().toString()); startActivity(Intent.createChooser(email, “Choose an email client from…”));
          4. Sample 2 – have an Activity that needs to open URL in a web browser on your Android device
            1. your Activity will send ACTION_WEB_SEARCH Intent to the Android Intent Resolver to open given URL in the web browser
            2. The Intent Resolver parses through a list of Activities and chooses the one that would best match your Intent, in this case, the Web Browser Activity;
            3. The Intent Resolver then passes your web page to the web browser and starts the Web Browser Activity
          5. Sample 3 – search as Londonmet on android search engine and it gives the result of londonmet in your an activity
        3. Deliver intents to different components:
          1. activities – Context.startActivity()
          2. services – Context.startService()
          3. broadcast receivers – Context.sendBroadcast()
        4. Intent components
          1. Intent” object as a message containing a bundle of information
            1. Information of interests for the receiver (e.g. data);
            2. Information of interests for the Android system (e.g. category);
          2. Component Name (i.e. the receiver)
            1. void setComponent(), or
            2. optional, i.e. implicit intent
          3. Action
            1. void setAction()
            2. A string naming the action to be performed;
            3. Pre-defined, or can be specified by the programmer;
              1. ACTION_CALL: Initiate a phone call
              2. ACTION_EDIT: Display data to edit
              3. ACTION_MAIN: Start as a main entry point, does not expect to receive data;
              4. ACTION_PICK: Pick an item from the data, return what was selected;
              5. ACTION_VIEW: Display the data to the user;
              6. ACTION_SEARCH: Performs a search
              7. Defined by programmer: it.example.projectpackage.FILL_DATA (package prefix + name action)
          4. Data
            1. void setData()
            2. Data passed from the caller to the called Component;
            3. Each data is specified by a name and/or type:
              1. Location of the data (URI) and Type of the data (MIME type);
              2. name: Uniform Resource Identifier (URI);
                1. scheme://host:port/path
                2. content://com.example.project:200/folder
                3. content://contacts/people
                4. content://contacts/people/1
              3. type: MIME (Multipurpose Internet Mail Extensions)-type
                1. Composed by two parts: a type and a subtype
                2. eg. Image/gif  image/jpeg; image/png; video/mp4; video/mpeg4; video/quicktime; video/ogg; application/;
          5. Category
            1. void addCategory()
            2. A string containing information about the kind of component that should handle the Intent;
            3. > 1 can be specified for an Intent
            4. Categories:
              1. CATEGORY_HOME: The activity displays the HOME screen;
              2. CATEGORY_LAUNCHER: The activity is listed in the top-level application launcher, and can be displayed;
              3. CATEGORY_PREFERENCE: The activity is a preference panel;
              4. CATEGORY_BROWSABLE: The activity can be invoked by the browser to display data referenced by a link.
          6. Extra
            1. void putExtras() getExtras()
            2. Additional information that should be delivered to the handler(e.g. parameters)
          7. Flags
            1. Additional information that instructs Android how to launch an activity, and how to treat it after executed;
        5. Intent types
          1. Explicit: target receiver is specified through the Component NameUsed to launch specific Activities;
            1. connected internal world of application, suppose if you wants to connect one activity to another activity, we can do this quote by explicit intent;
            2. typically used for application-internal messages – such as an activity starting a subordinate service or launching a sister activity
            3. // Explicit Intent by specifying its class nameIntent i = new Intent(FirstActivity.this, SecondActivity.class);// Starts TargetActivity startActivity(i);
          2. Implicit: The target receiver is specified by data type/names; The system chooses the receiver that matches the request;
            1. not name a target and the field for the component name is left blank;
            2. used to activate components in other applications;
              1. //Implicit Intent,
              2. Intent read1=new Intent();read1.setAction(android.content.Intent.ACTION_VIEW);read1.setData(ContactsContract.Contacts.CONTENT_URI);


            3. target component which receives the intent can use the getExtras() method to get the extra data sent by the source component;
    2. Learn how to use the Fragments and Intent in Android app development
  3. Lab5
  4. References
    1. Videos – Android tutorial for beginners – 77 – Fragment example.
    2. Videos – Android Intent Basic Example.
    3. Change default layout from ConstraintLayout to LinearLayout after AS 2.3.
      1. backup C:\Program Files\Android\Android Studio\plugins\android\lib\templates\activities\common\root\res\layout\simple.xml.ftl
      2. open simple.xml.ftl in editor (or simply Wordpad), then, replace contents below to simple.xml.ftl (may need to modify file permission in order to write and save):
        1. <?xml version=“1.0” encoding=“utf-8”?>
        2. <LinearLayout
        3.     xmlns:android=;
        4.     xmlns:app=;
        5.     android:layout_width=“match_parent”
        6.     android:layout_height=“match_parent”>
        7.     <TextView
        8.         android:layout_width=“wrap_content”
        9.         android:layout_height=“wrap_content”
        10.         android:text=“Hello World!”
        11.     />
        12. </LinearLayout>
      3. Then, new project will start with LinearLayout again;
  5. Follow-ups
    1. Research ConstraintLayout and parameters;
    2. Coding, coding and coding: 2 hours everyday…
    3. good habit to pre-lecture, but better read books and practice coding;


L5 - Fragments and Intents

CC7173 – WK5 (31/10/17)

CC7173 – WK4 (24/10/2017)

UI and Event handling

  1. Contents Summary
    1. GUI concept in Android
    2. Interfaces
    3. Layout options
    4. Android Event Management
  2. Contents detailed
    1. GUI concept in Android
      1. hierarchy of View and View group objects
        1. View: UI components such as button, textfields, imageviews
        2. ViewGroup: containers that have a layout defined controlling how View widget
          1. Controls location of Views in that ViewGroup
            1. LinearLayout: all children aligned in single direction, horizontally or vertically
            2. RelativeLayout: Child object relative to each other
            3. ListView: a list of scrollable items
            4. GridView: displays items in two-dimensional, scrollable grid
    2. Interfaces
      1. two ways you can create the interface(s) of your Application
        1. Code = write code using SDK with classes like LinearLayout, TextView, …
        2. XML = create XML files in res/Layout (i.e. main.xml) that contain Android XML view tags like <LinearLayout> <TextView>, etc
        3. XML would be better as it means a decoupling of design from Java code;
    3. Layout options
      1. Layouts defined with XML located in res/layout
        1. <TextView xmlns:android=”;

          1. xmlns:android  XML namespace declaration that tells the Android tools that you are going to refer to common attributes defined in the Android namespace. The outermost tag in every Android layout file must have this attribute;
          2. android:layout_width This attribute defines how much of the available width on the screen this View should consume. As it’s the only View so you want it to take up the entire screen, which is what a value of “fill_parent” means;
          3. android:layout_height This is just like android:layout_width, except that it refers to available screen height;
          4. android:text This sets the text that the TextView should display. In this example, you use a string resource instead of a hard-coded string value. The hello string is defined in the res/values/strings.xml file;
        2. Visual creation of XML file
          1. Create File-> New->XML -> Layout XML File
          2. name xml file and layout type
          3. Drag and Drop widgets-> Call alter properties
            1. example of a login page with textView_TopLabel, textView_login, editText_Login, textView_password, editText_Password, button_Enter;
        3. LinearLayout
          1. arranges its children in a single column or a single row;
          2. setOrientation(): set direction of the row can be set; default is horizontal;
          3. setGravity(): specifies the alignment of all the child elements;
          4. LinearLayout.LayoutParams: specify that specific children grow to fill up any remaining space in the layout by setting the weight member of
        4. RelativeLayout
          1. Benefits:
            1. Can give more complex interface
            2. Know what will look like on different sized devices
            3. Position relative to another position
          2. Drawback
            1. to be flat –meaning you don’t want/need to nest RelativeLayouts in each other –sometimes may impact speed in rendering
          3. Parameters in XML or map to method calls in Java RelativeLayout class
            1. Position relative to Parent
              1. android:layout_alignParentTop
              2. android:layout_alignParentBottom
              3. android:layout_alignParentLeft
              4. android:layout_alignParentRight
                1. VALUE = ‘true’ —If “true”, moves to that edge of Parent
              5. android:layout_centerVertical
                1. VALUE= “true” — If “true”, centers this child vertically within its parent.
            2. Position relative to another widget
              1. android:layout_below,
              2. android:layout_above,
              3. android:layout_toLeftOf,
              4. android:layout_toRightOf
                1. VALUE=“resource ID of other widget” — Positions the top edge of this view below/aboveof  the view specified with a resource ID;
                2. OR Positions the left edge of this view to the left/right of the view specified with a resource ID;
        5. GridLayout
          1. GridView, such as buttons in calculator
    4. Android Event Management
      1. Event listeners
        1. interface in the View class that contains a single callback method;
        2. to be called when the View is triggered by user interaction with the item in the UI;
      2. Event Listeners Registration
        1. process by which an Event Handler gets registered with an Event Listener so that the handler is called when the Event Listener fires the event;
      3. Event Handlers
        1. an event happens and we have registered an event listener for the event, the event listener calls the Event Handlers, which is the method that actually handles the event;
      4. Views that have events (android.widget), such as
        1. Button
        2. CheckBox
        3. DatePicker
        4. EditText
        5. ImageView
        6. SearchView
        7. Spinner
      5. Event Handling (
        1. STEP 1: Decide what Widgets who’s events to process
        2. STEP 2: Define an event listener
        3. STEP 3: Register event listener with the View
          1. View.OnClickListener (for handling “clicks” on a View), View.OnTouchListener (for handling touch screen events in a View), and View.OnKeyListener (for handling device key presses within a View)
        4. Sample of adding a button to a program-based interface
          1. Button specified in XML layout we want to process/handle
          2. Implement Event Handler
            1. TWO OPTIONS – separate class to handle event(s), OR have the Activity containing the button do the event handling
          3. Register Event Handler
            1. public class ExampleActivity extends Activity implements OnClickListener {
              protected void onCreate(Bundle savedValues) {
              …        Button button = (Button)findViewById(;   //STEP 1
              button.setOnClickListener(this);   //STEP 3 – registration
              // Implement the OnClickListener callback      //STEP 2 –event handler
              public void onClick(View v) {
              // do something when the button is clicked

            2. often you may do an anonymous inner class instead or a regular class if you want to reuse it
        5. Handling events by having Main Activity implement Listener Interface (Why slide 25 & slide 31 are the same??)
          1. Goal
            1. Change color of a TextView when Button or RadioButton is pressed. Different colors depending on which pressed
          2. Approach
            1. Use an external class that implements View.OnClickListener
            2. Import android.view.View.OnClickListener, then say “implements OnClickListener
          3. Advantages
            1. can pass arguments to change behavior
            2. Separate classes generally promote loose coupling
            3. if event handler can be applied to different controls, it can be change independently from rest of app;
            4. in most real situations, behavior is tightly coupled to app anyhow;
          4. Disadvantages
            1. if you want to call code in main Activity, you need reference
            2. Even then, that code in main Activity must be public
    5. XML Interface Creation: doing XML would be better as it means a decoupling of design from Java code;
    6. XML tags and explanation
    7. Event handling
      1. 3 steps
      2. Program of randomly change color
      3. Class
        1. Separate Listener Class
          1. public class ColorSetter Implements OnClickListener (
        2. Named Inner Class
          1. private class ColorSetter Implements OnClickListener (
  3. References
    1. Videos – Android Hands On Training Series – Exercise 1: Android UI Components, Activity, Fonts & Colors.
    2. Videos – Android development tutorial 3 – layout and buttons.
    3. Videos – Click events and Button onClick- Android Studio tutorial.
    4. Videos – Android Studio Tutorial – 08 – Respond to Button Click Events.
    5. Videos – Sketch UI Design to Android Studio XML Tutorial.
  4. Follow-ups
    1. proposal framework
      1. Practise Weekly Exercises
      2. Customize weekly exercises
      3. Try other web / book exercises
    2. read lot of materials
    3. widget
    4. Prepare programs, youtube, questions before class
    5. familiar with components within codes
      1. declaration
      2. definition
      3. registration
      4. functions / class calling
    6. What is the difference between inner class and public class?
      1. Compare the code in Excel
CC7173 – WK4 (24/10/2017)

SECOPS – CCSA study log (210-255)

  1. Objectives – learn and exam
    1. Cisco materials:
  2. Content summary
    1. Defining the Security Operations Center
    2. Understanding NSM Tools and Data
    3. Understanding Incident Analysis in a Threat  Centric SOC
    4. Identifying Resources for Hunting Cyber Threats
    5. Understanding Event Correlation and Normalization
    6. Identifying Common Attack Vectors
    7. Identifying Malicious Activity
    8. Identifying Patterns of Suspicious Behavior
    9. Conducting Security Incident Invesigations
    10. Describing the SOC Playbook
    11. Understanding the SOC metrics
    12. Understanding the SOC WMS and automation
    13. Describing the Incident Response Plan
    14. Appendix A – Describing the Computer Security Incident Response Team
    15. Appendix B – Understanding the use of VERIS
  3. Content details
    1. Defining the Security Operations Center
      1. Types of Security Operations Centers
        1. SOC: center for network security event monitoring and incident response
        2. responsible for detecting, analyzing, and reporting unauthorized or malicious network activity
        3. 3 types (vary from different job roles, tools and technologies)
          1. Threat-centric SOCs
            1. proactive hunts for malicious threats
            2. addresses the entire attack continuum – before / during / after;
          2. Compliance-based SOCs
            1. Against reference configuration templates and std system builds;
            2. relies on detecting unauthorized changes and existing config problems;
            3. Key: link risk mgt and incident response practices to an automated system compliance process;
            4. such as benchmarks by Center of Internet Security (CIS) or PCI DSS 2.0 (Payment Card Industry);
          3. Operational-based SOCs
            1. focus on maintaining the operational integrity and internal monitoring with techniques that are tailored for an organization‘s specific network environment;
              1. Tier 1 SOC analyst: deploying tools
              2. Tier 2 SOC analyst: developing tools
            2. term: CSIRT (Computer Security Incident Response Team)
            3. Addressing operational issues within an organization requires operational solutions and operational competence, not just enable features on a device when there is security issue;
          4.  Example of a SOC Architecture
            1. automate and customize feeds / inputs to database in which alerts are triggered and ease for analysis;
      2. SOC Analyst Tools
        1. Functions
          1. Network mapping
          2. Network monitoring
          3. Vulnerability detection
          4. Penetration testing
          5. Data collection
          6. Threat and anomaly detection
          7. Data aggregation and correlation
        2. Example tools
          1. Security Onion: Linux distribution with Log mgt, network security monitoring, IDS capabilities;
            1. Composed of Snort, Suricata and so on…
          2. Network analyst tools: Wireshark / Netwitness / OSSEC / NetFlow / Cisco Stealthwatch;
          3. Penetration testing tools: exploit weakness;
            1. eg. Kali Linux with tools such as Metasploit Framework, Armitage, and SET (Social Engineer Toolkit)
            2. start vulnerability assessment
            3. eliminate those weaknesses to an acceptable level
            4. perform a penetration test on improved posture;
      3. Data Analytics
        1. examining and deciphering raw data or data sets with the purpose of drawing conclusions;
          1. Tier 1 analyses real-time data for short run while escalate potential intrusions to Tier 2 to response;
          2. Dynamic analysis:  testing and evaluation against real-time data;
        2. Log mining
          1. SIEM tools such as Splunk can help a SOC collect and normalize large amounts of disparate log data;
          2. Sequencing: reconstructing network flow
          3. Path analysis: interpretation of a chain of consecutive events
          4. Log clusthering: mine through large amounts of log data to build profiles and to identify anomalous behavior
          5. forecast future attacks > Predictive analysis
        3. Raw Network Packet Capture Analysis
          1. Netflow / WireShark / tcpdump
        4. Real-time Rule-Based Alerts
          1. Alerts from Users / HelpDesk / Hardware / Software
      4. Hybrid installations: Automated Reports, Anomaly Alerts
        1. automate as many tasks as possible in streamline
          1. Ticket generation
          2. False positive alert handling
          3. Report generation: weekly / monthly summaries
        2. Anomaly detection: alerts which are based on volume or feature patterns
          1. Volume-based anomaly alerts can come from: Statistical analysis / Frequency analysis / Time-series forecasting
          2. feature-based anomaly detection
      5. Sufficient Staffing Necessary for an Effective Incident Response Team
      6. Roles in a Security Operations Center
        1. SOC manager
          1. prioritizing work and organizing resources with the goal of detecting, investigating, and mitigating incidents that could impact the business;
          2. determines both the day-to-day activities and the base skills that are required (workflows and SOPs) by the security analyst to perform the job successfully;
        2. Tier 1 security analyst
          1. Continuously monitors the alert queue
          2. Triages security alerts
          3. Monitors the health of the security sensors and endpoints
          4. Collects data and context necessary to initiate Tier 2 work
        3. Tier 2 security analyst
          1. Performs deep-dive incident analysis by correlating data from various sources
          2. Determines if a critical system or data set has been impacted
          3. Advises on remediation
          4. Provides support for new analytic methods that are used in threat detection
        4. Tier 3 security analyst
          1. Possesses in-depth technical knowledge on the network, endpoint, threat intelligence, forensics, malware reverse engineering, and the functioning of specific applications or underlying IT infrastructure
          2. Acts as an incident hunter, not waiting for escalated incidents
          3. Closely involved in developing, tuning, and implementing threat detection analytics
      7. Develop Key Relationships with External Resources
        1. TALOS
        2. US-CERT
        3. FiRST
        4. malwr
        5. OVE
        7. PhishTank
      8. Challenge
    2. Understanding NSM Tools and Data
      1. NSM (network security monitoring) Tools
        1. SOC analysts rely on NSM data
        2. functions
          1. collecting syslog messages
          2. moving messags from a flat log file to a database
          3. automate reports / dashboards / real-time query
        3. Commercial / Open source / homegrown
      2. NSM Data
        1. 6 types
          1. Session Data (Tool: ?Netflow)
            1. summary data that is associated with network conversations (who and when);
            2. IP 5-tuple
          2. Full packet capture (Tool: ?TCPdump / Wireshark)
            1. records all the network traffic, packet by packet;
            2. in PCAP format
          3. Transaction data
            1. between session data and full packet capture
            2.  captures the details that are associated with requests and responses;
              1. eg. log GET by client; log SMTP connections
          4. Alert data
            1. by IPS system
          5. Statistical data
            1. NSM data is collected over time, the data can be processed to produce statistical data
            2. performance ratio; summary
            3. produces baselines
            4. Deviations from normal are called anomalies
          6. Metadata
          7. Correlation is key for analysis
            1. eg. same time stamp of numerous packets from same IP address;
            2. connections with malicious IP addresses;
      3. Security Onion (Linux distribution that focuses on NSM)
        1. Security Onion is a turnkey NSM solution
        2. deployed as a simple standalone system or a distributed deployment;
        3. Security Onion use netsniff-ng to perform full packet capture
      4. Full Packet Capture
        1. in PCAP (packet capture) format
        2. Consider:
          1. Location: sensing interfaces are placed at chokepoints / ingress points in the network;
          2. Method of network connection
            1. sensing interface connected to mirror SPAN port
            2. network tap
            3. inline (reliable) where the sensor uses two interfaces and traffic is forced through the sensor between these two interfaces
          3. NIC configuration
            1. checksum offload and TCP segmentation offload to improve system and network performance
          4. Storage size: 540GB / day
      5. Session Data
        1. IP 5-tuple
        2. capture by Bro
        3. ELSA takes the flat Bro logs and other flat log sources and stores them in a relational MySQL database with Sphinx indexing
      6. Transaction Data
        1. audit trails of client requests and server responses (SMTP / HTTP / DNS…);
      7. Alert Data
        1. produced by IDS and IPS systems
        2. analyst must:
          1. understand whether the IDS is capable of dropping malicious traffic;
          2. know how to examine the alert data to determine the actions that the IDS has taken;
      8. Other Data Types
        1. Extracted content: artifacts from real-time traffic streams or PCAP files;
          1. eg. by Bro or NetworkMiner;
          2. eg. Bro extract all email attachments;
        2. Statistical Data by ELSA
      9. Correlating NSM Data
        1. 5 IP-tuple
      10. Explore Network Security Monitoring Tools
      11. Challenge
    3. Understanding Incident Analysis in a Threat Centric SOC
      1. Classic Kill Chain Model Overview
        1. R W D E I C A
      2. Kill Chain Phase 1: Reconnaissance
        1.  intelligence gathering
      3. Kill Chain Phase 2: Weaponization
        1. development of a cyber weapon that is based on reconnaissance information;
        2. such as viruse, code injection, email or phishing campaigns;
      4. Kill Chain Phase 3: Delivery
        1.  transmission of the payload to the target via a communication vector
        2. such as email attachments / phishing emails / redirection / USB devices;
        3. Deliver undetectedly is key to success: encryption, re-appeareace;
      5. Kill Chain Phase 4: Exploitation
        1. describes what occurs once the malicious code is executed;
        2. Threat actors / threat agent
        3. 3 typical weaknesses: Applications / OS / Users;
        4. Selection of the exploit is important -> intended effect and gain control;
      6. Kill Chain Phase 5: Installation
        1. also as persistence phase
        2. describes actions taken by the threat actor to establish a back door to sustain persistent access;
          1. especially survive a system reboot;
      7. Kill Chain Phase 6: Command-and-Control
        1. outbound to an Internet-based controller in order to establish a communications channel;
          1. eg. long DNS queries that are initiated from multiple inside hosts to domains using randomized names;
      8. Kill Chain Phase 7: Actions on Objectives
        1. actions taken by the threat actor that are objective-dependent
      9. Applying the Kill Chain Model
        1. Recon: Reconnaissance / gathers information
          1. hardened by NFFW
        2. Stage: Weaponization, cyber criminals try to fool users into opening emails or clicking on links;
        3. Launch: Delivery, Staging sites redirect from trustworthy-looking sites to sites that launch exploit kits and/or other malicious content;
        4. Exploit: exploited to take control of the user’s system
          1. hardened by network-based and host-based anti-malware solutions
        5. Install: infect and encrypt the victim’s system—the ransomware payload.
          1. hardened by network-based and host-based anti-malware solutions
        6. Callback: CnC, the malware calls home to a CnC server, where it retrieves keys to perform the encryption or receive additional instructions;
        7. Persist: objectives
      10. Diamond Model Overview
        1. framework for analyzing events in a repeatable way so that the threats can be organized, tracked, sorted, and countered; like PDCA;
        2. Adversary: entity responsible for conducting an intrusion
          1. adversary operator is the person who is conducting the intrusion
          2. adversary customer is an entity that benefits from the intrusion
        3. Capability: tool or technique that the adversary may use in an event
          1. adversary arsenal is the complete set of the adversary’s capabilities;
        4. Victim
          1. target of the adversary
          2. Victim persona is the group of people or organization being attacked;
          3. Victim asset is the physical or logical target of the attack
        5. Infrastructure
          1. the physical or logical communications nodes that the adversary uses to establish and maintain command and control over their capabilities, such as Internet / USB sticks
          2. 3 types
            1. Type 1: owned and controlled by the adversary
            2. Type 2: co-opted by the adversary, but is owned by a third party
            3. Service providers: entities that provide type 1 and type 2 infrastructures and include entities such as an ISP
          3. Questions utilized in the diamond model
            1. What infrastructure was utilized?
            2. What was the target (victim)?
            3. What methods (capability) were used?
        6. Meta-features
          1. Timestamp: When start or end:
          2. Phase: group of events
          3. Result: Success / Failure / Unknown
          4. Direction: eg. adversary to victim / victim to adversary
          5. Methodology: generic class of activity used, such as DoS / phishing
          6. Resources: external resource that is used by adversary
      11. Applying the Diamond Model
        1. fundamentally supports analytic pivoting;
        2. adversary-centered approach: monitoring an adversary directly to discover them
        3. victim-centered approach: perform reactive network and host monitoring, detection, and defense operations
        4.  threat intelligence platform called ThreatConnect
      12. Exploit Kits
        1. sets of tools that are utilized to gain access to a targeted host;
          1.  launching platform to deliver the payload to the targeted system
        2. the ease with which it can be used
        3. If the targeted host is patched and up-to-date on all applications (Flash, Java, or Silverlight), most exploit kits will stop at the landing page;
        4. Well known Exploit Kits:
          1. Neutrino targets Java runtime environment, drops ransomware on target systems
          2. Magnitude commonly utilized to drop ransomware on target systems
          3. Angler is a very versatile, utilizes a robust toolkit
          4. Nuclear: largely targets vulnerable Adobe Flash vulnerabilities, largely safe from AV detection.
      13. Investigate Hacker Methodology
      14. Challenge
        1. reconnaissance phase = A solid network security posture with firewalls and intrusion detection can prevent leaking more information
        2. delivery phase = Knowledge of existing ransomware attacks and communication vectors, can aid in the prevention of delivery
        3. installation phase = User access controls and strict limits to privilege levels can also help mitigate this stage
        4. command-and-control = Network security monitoring tools can greatly help identify this phase
        5. actions on target = Unusually high amounts of traffic, connections to IP addresses that are foreign or unrecognizable, or other activities that seem out of the ordinary can indicate this type of attack
    4. Identifying Resources for Hunting Cyber Threats
      1. Cyber-Threat Hunting Concepts
        1. threat-centric SOC
          1. involves a proactive approach to detecting malicious activity that is not identified by traditional alerting mechanisms;
          2. correlate the data and determine if there is cause for further investigation
      2. Hunting Maturity Model (HMM)
        1. HM0 to HM4
        2. levels increase, analysts become more knowledgeable and sophisticated in their tactics; and more proactive;
        3. HM0: relies on alerting; not collect information from any systems outside;
        4. HM1: rely on an IDS for alerts, but also collect information from their systems to look for new threats;
        5. HM2: able to incorporate hunt techniques from external sources into their own hunt operations;
          1. Most organizations with active performance will be in this level;
        6. HM3: innovative; also publish hunting procedures;
        7. HM4: able to automate many tactical-level analysis procedures;
      3. Cyber-Threat Hunting Cycle
        1. Hypothesis
          1. looking at the system from the perspective of the attacker
        2. Investigate
          1. uses tools and techniques to investigate the hypothesis
        3. Uncover
          1. TTP: tactics, techniques and procedures
          2. IOCs: Indicator of Compromise
          3.  where the ultimate success of the cycle is achieved
        4. Inform and Enrich
      4. Common Vulnerability Scoring System (CVSS)
        1. chances of being compromised in the event of an attack and potential severity of damage;
        2. latest version at 3.0;
        3.  provide the end user with an overall composite score representing the severity and risk of a vulnerability
        4. 3 metrics groups: Base Metrics / Temporal Metrics / Environmental Metrics
          1. Base Metrics: variables that are constant over time and across user environments
            1. exploitability metrics
              1. attack vector (AV): Local / Adjacent / Network / Physical; the context by which vulnerability exploitation is possible; higher value, more remote an attacker is from the vulnerable component;
              2. attack complexity (AC): Low / High; conditions beyond the attacker’s control that must exist in order to exploit the vulnerability;
              3. privileges required (PR): None / Low / High; level of privileges an attacker must possess before successfully exploiting the vulnerability;
              4. user interaction (UI): None / Required; whether or not a user other than the attacker must participate in;
              5. scope (S): Unchanged / Changed; ability for a vulnerability in one software component to impact resources beyond its means, or privileges;
            2. impact metrics
              1. confidentiality (C): None / Low / High; impact to the confidentiality of the information resources that are managed by a software component due to a successfully exploited vulnerability;
              2. integrity (I): None / Low / High; impact to integrity of a successfully exploited vulnerability;
              3. availability (A): None / Low / High; impact to the availability of the impacted component resulting from a successfully exploited vulnerability
          2. Temporal Metrics
            1. Exploit Code Maturity (E): Not Defined / Unproven / Proof-of-Concept / Functional / High; likelihood of the vulnerability being attacked, and it is typically based on the current state of exploit techniques, exploit code availability, or active, “in-the-wild” exploitation;
            2. Remediation Level (RL): Not Defined / Unavailable / Workaround / Temporary fix / Official fix; patching practices;
            3. Report Confidence (RC): Not Defined / Unknown / Reasonable / Confirmed; degree of confidence in the existence of the vulnerability and the credibility of the known technical details;
          3. Environmental Metrics: to customize the CVSS score depending on the importance of the affected IT asset to a user’s organization
            1. Security Requirements (CR, IR, AR): Not Defined / Low / Medium / High; depends on user’s organization;
            2. Modified Base Metrics: MAV, MAC, MPR, MUI, MS, MC, MI, MA; to adjust the base metrics according to modifications that exist within the analyst’s environment
      5. CVSS v3.0 Scoring (maintained by FIRST (
        1. combining all the metric values according to specific formulas;
        2. to help prioritize remediation efforts;
        3. Basic scoring:
          1. once base scoring is computed, it is not expected to be changed;
          2.  has the largest bearing on the final score;
        4. Temporal scoring:
          1. for publication and modifies the base score;
          2. introduces mitigating factors that reduce the score of a vulnerability;
          3.  represents vulnerability urgency at specific points in time
        5. Environmental scoring:
          1. represents a snapshot in time and is tailored to a specific environment;
      6. CVSS v3.0 Example
        1. CVSS v3.0 score of the MySQL Stored SQL Injection vulnerability CVE-2013-0375.
      7. Hot Threat Dashboard
        1. graphical depiction of currently monitored threats;
        2. to define the criteria that must be met in order for a threat to be considered hot;
        3. Goal: to maintain an actionable list of current top hot threats (> 15);
        4. Posting a Hot Threat
          1. TLP (Traffic Light Protocol): set of designations that are used to ensure that sensitive information is shared appropriately;
            1. Red <> Amber <> Green <> White;
            2. Red: Not for disclosure, which is restricted to participants only
            3. White: Disclosure is not limited;
        5. Reviewing a Hot Threat: senior security investigator (Investigations Manager) will review and validate it to become active;
        6. Monitoring Hot Threats:
        7. Retiring Hot Threats
        8. Hot Threat Challenges
      8. Publicly Available Threat Awareness Resources
        1. OWASP (Open Web Application Security Project)
          1.  resources ranging from guides, cheat sheets, and applications to identify attacks;
          2. publish top 10 rated vulnerabilities per 3 years
            1. Injection: improper sanitization of user input for a command or query
            2. Broken authentication and session management: to tie a improper ended session to an individual user;
            3. XSS
            4. Insecure direct object references: by lax checks to ensure a user requesting a resource actually has permissions to access that resource; eg. address with user ID;
            5. Security misconfiguration: by improper configurations of any part of the application stack; eg. default config.;
            6. Sensitive data exposure
            7. Missing function level access control
            8. Cross-site request forgery (CSFR): by a failure to ensure that each request was properly originated by a user
            9. Using components with known vulnerabilities: by a failure to properly patch
            10. Unvalidated redirects and forwards
        2. Spamhaus Project
          1.  analyst should use Spamhaus to determine whether a suspected email is in fact on the list of known malicious spam;
          2. Top 10 list and, ;
            1. SBL:  Spamhaus Block List, list targeting IP addresses of known spammers;
            2. Exploits block list: XBL, hosts that are known to be infected or misconfigured and facilitating illegitimate traffic;
            3. Policy block list: PBL,  do not have legitimate reason to be directly relaying email;
            4. Domain block list: DBL, list of domains that are being utilized in spam;
        3. Alexa: website traffic analytic
        4. Farsight Security’s DNSDB:  provides information to security analysts about DNS
      9. Lab: Hunt Malicious Traffic
      10. Challenge
    5. Understanding Event Correlation and Normalization
      1. Event Sources
        1. Types
          1. DHCP server: transaction data of IP assignments;
          2. DNS server: transaction data of queries and responses;
          3. AAA server: Alert data of successful / failed authentication and authorization events;
          4. NetFlow-capable network device: Session data; Statistical data
          5. IPS: Alert data from triggers of rules / signatures;
          6. Firewall: Session data, Packet captures, Statistical data;
          7. Proxy (web and email): transaction data, extracted data;
        2. Identity and Access Managment: provide AAA services
        3. AntiVirus: alert data;
        4. Application Logs: transactional and statistical data
      2. Evidence
        1. Types
          1. Direct evidence: not require any reasoning to reach the conclusion;
          2. Circumstantial evidence: Requires an inference linking the evidence to the conclusion
          3. Corroborating evidence: supports an assertion that is supported by previously obtained evidence
          4. best evidence. Submitting the output of a sandbox detonation report as evidence, instead of submitting the malware file;
        2. Digital Forensics
          1. Collection
          2. Examination
          3. Analysis
          4. Reporting
      3. Security Data Normalization
        1. manipulating various security event data and fitting it into a common schema;
        2. parsers (eg. ELSA) algorithmically take the event data and extract the relevant characteristics and fill in the appropriate fields in the common schema;
      4. Event Correlation
        1. mutual relationship or connection between two or more things;
        2. MUST use the IP 5-tuple to correlate events
        3. correlated events provide much more detail and context to the analyst than can be obtained from any single event;
        4. Correlation is performed after normalization;
      5. Other Security Data Manipulation
        1. Aggregation: data mining technique where data is gathered to get more information about particular variables;
          1. eg.  ELSA may be queried with simply an IP address with multiple matches;
        2. Summarization
          1. data mining technique in which compact descriptions of key data set qualities are produced;
            1. in a graphical format or in a tabular format;
            2. useful for analyzing aggregated data;
        3. Deduplication: after normalizationpresent all the relevant details that are pulled from a collection of overlapping data in a concise format;
      6. Lab: Correlate Event Logs, PCAPs, and Alerts of and attack
      7. Challenge
    6. Identifying Common Attack Vectors
      1. Obfuscated Javascript
        1. Code obfuscationdisguise the appearance of source code running on a system;
        2. Employed to reduce the overall size of the software code or application;
        3. renders JavaScript source code into a form that is not easily readable, with the intent of disguising the intended function of the code;
        4. Original: prevent JavaScript source code from being analyzed or stolen in order to protect the intellectual property;
        5. Common techniques:
          1. Automatically renaming variables to random and meaningless names;
          2. White-space randomization within codes to increase readability;
          3. Self-modifying source code that rewrites itself as it is executed;
          4. Using character codes and string manipulation that is combined with the misuse of eval expressions ‘eval();
          5. Hackvertor is an online, community-based encoding tool by security Pros.
          6. JSDetox is a JavaScript malware analysis tool that utilizes de-obfuscation techniques and an execution engine that emulates HTML DOM.
      2. Shellcode and Exploits
        1. payload that is attached to an exploit that will execute the desired actions (add backdoor / create VNC session) of the threat actor;
        2. provide the threat actor with command shell access on the system;
        3. DEP prevents the use of the stack memory space for execution;
        4. ASLR will randomize the memory addresses in use, which can help ensure that an attacker cannot predict; but could be bypassed by egg-hunting;
        5. Two variations of Shellcode payloads:
          1. Staged: designed to be very compact to fit within memory space limitations for a particular exploit
          2. Unstaged: with all portions of the payload residing within a single memory space
        6. Detection:
          1. Snort IPS
          2. traversing a network is to focus on detecting a pattern of code that contains a sequence of NOP instructions, commonly referred to as a NOP sled;
      3. Common Metasploit Payloads
        1. Metasploit Payloads: modules utilized during exploitation events;
        2. 3 types of payloads within Metasploit:
          1. Singles:
            1. self-contained payloads that function on their own;
            2. not dependent on the Metasploit framework for execution;
            3. well documented and the process of gaining execution of a single is easily detected and blocked;
            4. eg. Netcat: after transfer, executed remotely so that it can begin performing the actions;
          2. Stagers
            1. set up a network connection between the attacker and victim;
          3. Stages
            1. used with the stagers and while much larger in comparison provide increased functionality;
            2. self-contained and contain everything outside of the network;
          4. Others
            1.  traffic that is generated by the payload would draw attention;
            2. Meterpreter: sophisticated because it is executed directly in memory;
            3. PassiveX: to circumvent outbound firewalls;
            4. reflective DLL injection: a stage payload is injected into a compromised host process running in memory, such as VPNC and Meterpreter make use of reflective DLL injection ;
      4. Directory Traversal
        1. by improper checking or validation of user-supplied input to access file system; such as thru web browser;
        2. entered several ..\ sequences into the URL;
        3. Modern web-server applications have included input checking and patched;
      5. SQL Injection
        1. Used to perform attacks:
          1. Authentication bypass
          2. Information disclosure
          3. Compromised data integrity: alteration of the contents of a database;
          4. Compromised availability of data: delete information with the intent to cause harm or delete log or audit information in a database;
          5. Remote command execution
        2. IPS signatures
      6. Cross-Site Scripting
        1. maliciously causing a script, typically JavaScript, to execute in the browser;
        2. 2 types:
          1. Stored (persistent):
            1. embeds the malicious code within the page that is stored on the web server itself;
            2. If the server fails to properly sanitize input, the attacker code will be posted to the page and displayed to all visiting users;
          2. Reflected (nonpersistent):
            1. includes HTML code within a link to a web address, knowing the linked page will fail to sanitize the included HTML code
          3. OWASP provides resources of best practices for developing web apps such as XSS Filter Evasion Cheat Sheet for testing;
      7. Punycode
        1. normally in ASCII format; but Unicode is needed by some countries;
        2. Punycode is a system for representing Unicode characters in an ASCII-only format to ensure compatibility with older DNS systems;
        3. threat actor: phishing > redirection > stager / exploit kit…
        4. such as;
      8. DNS Tunneling
        1. other protocol can be tunneled through DNS;
        2.  used for CnC, data exfiltration, or tunneling of any IP traffic;
        3. DNS tunneling tool such as Iodine
        4. uses the malicious server as the authority server for the specific domain
        5. Benefits: not often detected as DNS traffic is normal;
        6. Drawback: slow speed;
        7. Detection:
          1. Active examining payloads for unusual content, packet size, bandwidth, frequency of requests, and looking for unusual hostnames;
      9. Pivoting (redirection)
        1. use a compromised computer to attack other computers within the same network to avoid restrictions of firewalls;
        2. goal: expand access in the network of compromised host;
      10. Lab: Investigate Browser-based attacks
      11. Challenge
    7. Identifying Malicious Activity
      1. Understanding the Network Design
        1. obtain a network topology map of connected devices; or otherwise conducting their own vulnerability scan;
        2. inventory list of all network-based appliances;
        3. Categorizing the assets by priority such as critical, important, or sensitive;
        4. Identify the physical location of specific security-related devices and their data logging output;
      2. Identifying Possible Threat Actors
        1. person or groups who start a malicious incident;
        2. Types
          1. Script Kiddies: unskilled, use public tools;
          2. Hacktivists (Hack Activism)
            1. promoting their own political agenda;
            2. eg. Lulz Security (LulzSec) and Anonymous
            3. not interested in covering their tracks nor disguising their presence
        3. Organized Crime: driven by profits
        4. State-Sponsored / Nation-State Actors
          1. often referred to as APTs
        5. Insider Threat
          1.  motivated by financial gain or intent of harming organization;
          2. at risk if it is not adequately monitoring user and network system patterns for anomalous behaviors;
      3. Log Data Search
        1. ELSA (Enterprise Log Search and Archive):  syslog compiler and search querying tool;
          1. to correlate network and host activity by inspecting relevant syslog; and  log ingest capabilities;
        2. Portions of syslog (the RFC 3164):
          1. facility code: different OS or syslog implementations may vary;
          2. security level: 0-7
          3. message:
            1. TAG: program or processes that generated it;
            2. CONENT: content
          4. searching syntax (Boolean operators / directives):
            1. OR
            2. groupby
          5. Modeling Network attacks:
            1. Deterministic assessment method:
              1. scenario assessment on a small or very limited set of variables
              2. relies on known data values to yield a single outcome for each proposed scenario
              3. low degree of speculation
            2. Probabilistic Impact Assessment
              1. wide range of probable scenarios, which provide a distribution of all possible outcomes
              2. high degree of speculation;
      4. NetFlow as a Security Tool
        1. info of I5-tuple information, the time of the communication, and the amount of data transferred;
        2. Factors / Symptoms:
          1. Long active duration;
          2. application is undefined;
          3. no return traffic;
          4. inbound connection to the domain controller using unknown application;
      5. DNS Risk and Mitigation Tool
        1. DNS poisoning
        2. DNS tunnelling
        3. craft special DNS TXT records that contain small amounts of exfiltrated data;
        4. suspicious domain names may contain credit card no. in hex
        5. Types
          1. Fast Flux and Botnets
          2. Double IP Flux
          3. DGA (Domain Generation Algorithm)
      6. Lab: Analyze Suspicious DNS Activity
      7. Challenge
    8. Identifying Patterns of Suspicious Behavior
      1. Network Baselining
        1. profile for how a system or network normally behaves; how different the system / network behaves from normal; will it break at some point?
        2. baselining network traffic can include NetFlow and passive DNS statistics;
        3. A baseline of logging and application transactions;
        4. Core Baseline Flowchart
      2. Identity Anomalies and Suspicious Behaviors
        1. Malicious network traffic, or traffic tunnelling
        2. Log event data is another area that is important to monitor relating to the baseline:
          1. not normal user login behaviors / time;
          2. logging such as system restarts and application crashes are also very useful in identifying suspicious behavior;
        3. Powershell usage should be monitored for suspicious activity;
          1.  Powershell logs can be the source of a flag
      3. PCAP Analysis
        1. fill in some of the unknown information to build a more complete picture of the event;
        2. Analysis via
          1. source IP and destination IP pairs;
          2. source and destination ports pairs;
          3. network protocol that is anomaly;
          4. any payloads that were part of the suspicious behavior
        3. Filtering: REGEX. (regular expression) is a sequence of characters that define a search pattern;
      4. Delivery
        1. File analysis begins with identifying the suspicious files themselves and their child / parent processes;
        2. sandbox allows the files to be executed in a controlled environment, especially useful for reverse engineering;
        3. report. Using hashes from the submitted samples, will attempt to match the file with any previously known malware
        4.  malware component “dropper”: downloads file over the network and then executes that file;
      5. Lab: Investigate Suspicious Activity Using Security Onion
      6. Challenge
    9. Conducting Security Incident Investigations
      1. Security Incident Investigation Procedures
        1. 5W1H
        2. Tier 1 SOC analysts do not perform deep analysis of malware
        3. VirusTotal is a very useful tool for an analyst when investigating whether a suspected file is malicious or of no concern to the investigation
        4. Geolocation services: latitude and longitude, IP addresses
          1. Such as:, Virus Total,…
      2. Threat Investigation Example: China Chopper Remote Access Trojan
        1. China Chopper RAT is a back door for remotely accessing a compromised web server;
          1. two components: client interface (caidao.exe) and the web shell file on server;
          2.  goal of stealing sensitive data by gaining access;
          3. web-shell files are placed on a compromised web server, and the attacker uses a custom web-shell client to perform additional exploit objectives;
          4.  Difficulties:
            1. the web shell application portion of the RAT is extremely basic and small, under 4KB, which leaves only the attacker’s caidao.exe client communications ;
            2. if the web shell is deployed on a secured web server using TLS or SSL;
          5. Investigation steps:
            1. Alert > Detect > Confirm > Remediate > Resolve;
              1. query the source and destination IP addresses with tools such as ELSA, Sguil, and Bro;
              2. analyze the HTTP traffic between the caidao.exe client and the web shell;
          6. Once discovered compromised hosts, better format or re-imaging OS;
      3. Lab: Investigate Advanced Persistent Threats
      4. Challenge
    10. Describing the SOC Playbook
      1. Security Analyticsclose the time gap between network compromise and threat detection
        1. purpose of security analytics is to :
          1. detect attacks as fast as possible,
          2. stop an attack, and
          3. provide detailed information to reconstruct an attack
        2. by collecting, correlating, and analyzing a wide range of event data
        3. Playbook: prescriptive collection of repeatable plays (reports and methods) to detect and respond to security incident
        4. Mitigation: few short-term ways to stop the threat
          1. DNS sinkhole which blocks suspicious DNS queries by domain names;
          2. BGP black-holing, which quickly blocks IP addresses across the enterprise in seconds;
          3. Device quarantine using an IAM security device
          4. Using firewall rules to block the attack
        5. Remediate: Medium- and long-term fixes
          1. Requires partnerships with IT and network teams
          2. requires the security architecture to be reviewed and may require some system modifications
      2. Playbook Definition (my thought: AI enabled in extention?)
        1. complex queries or code to find “bad stuff”; self-contained, fully documented, prescriptive procedures for finding and responding to undesired activity;
        2. is living document that brings a dramatic increase in fidelity and new detection ideas, which leads to better detection
        3. Event play in the playbook
          1. Report ID: Identifies the particular play, and provides a high-level description of the play
          2. Objective
          3. Data query: 
          4. Action
          5. Analysis: Provides the bulk of the documentation of the play, and how to interpret and act on the results of the query
          6. Reference: Allows for the documentations of any additional useful information
      3. What is in a Play?
        1. Report Identification
          1. Report Unique ID = eg. 100003
            1. leading digit of the unique ID may be used to indicate the data source;
          2. Report Type = eg. HF / eg. INV
            1. High fidelity (HF) means that all events from a report can be automatically processed, cannot be triggered by normal or benign activity
              1. Hardcoded strings, known host names or IPs, and regular expressions that match a particular exploit are good examples of things that can be included in a high-fidelity report,
            2. Investigative (INV) event from a report might detail a host infection, describe a policy violation, trigger on normal activity (which may require tuning), require additional queries
              1. Reports that cannot indicate with 100 percent certainty that an event is malicious are deemed to be high fidelity;
          3. Event Source = IDS
            1. The event source identifies which source, that the report queries
          4. Report Category = MALWARE
            1. MALWARE = is malicious activity or indicators of malicious activity on a system or network
          5. Description: BOT-C2
            1.  free-text description component may provide a brief summary of detection;
        2. Objective
          1. “what” and “why” of a play;
        3. Data Query (working)
          1. implements the objective and produces the report results
          2. where the play objective changes from an English sentence to a machine-readable query
        4. Action
          1. documents the actions to take during the incident response phase
        5. Analysis
          1. documentation and training material that is needed to understand how the data query works
          2.  how to interpret and act on the results of the query
          3.  discusses the fidelity of the query, what the expected true positive results look like, the likely sources of false positives, and how to prioritize the analysis
          4. help security analysts who are running the play to act on the data
        6. Referenece
          1. can be managed using a tracking system such as Bugzilla (bug and ticket tracking system) – track changes and document the motivation for those changes;
          2. Comments allow for discussion
          3.  additional management options like retiring reports and reopening reports
      4. Playbook Management System:
        1. Create a custom field.
        2. Track the play progress and life cycle.
        3. Provide basic notification (such as email and RSS).
        4. Run queuing and assignment functions.
        5. Automate reports and metrics.
        6. Document and log changes.
        7. New and relevant plays must be developed continually and managed using a play management system
      5. Lab: Explore SOC Playbooks
      6. Challenge
    11. Understanding the SOC metrics
      1. Security Data Aggregation
        1. SIEM: provide real-time reporting and analysis of security events;
          1. collects, sorts, processes, prioritizes, stores, and reports the alarms;
          2.  creates a “single pane of glass” to monitor the enterprise
          3. goal: to reduce the time that is needed to detect, and to contain the threats;
          4. eg. host-based security controls, which can report the malicious activity to the SIEM. Then, analysts could correlate the incidents to single source;
          5.  historical perspective enables the security analysts to establish a baseline
          6.  historical perspective enables the security analysts to establish a baseline, factors are:
            1. total size of log data and the time range;
        2. Main SIEM functions
          1. Log collection of event records from sources
          2. Log normalization to map log messages to a common Schema data model
          3. Events and logs correlation to speed the detection
          4. Reporting tools to address regulation compliance reporting requirements
          5. Open source tools such as Splunk that are hosted on GitHub;
      2. Time to Detection (TTD) ( or dwell time)
        1. Stages: Malicious Event > Detected > Contained > Mitigated
        2. Duration from “Malicious Event” to “Detected”
        3. Metrics for performance / effectiveness of SOC
          1. time to detection, time to containment, and the time to mitigation;
          2. currently, TTD = 100-200 days
        4. Reduce TTD by
          1. improving and mature SOC processes, people, and technologies;
          2. effective security controls that work across the attack continuum
      3. Security Controls Detection Effectiveness
        1. False negative:
          1. High priority. Did not acted with malicious activity;
        2. False positive:
          1. acted with no malicious activity;
          2. significantly drain the SOC resources
        3. True negative: not acted with no activity;
        4. True positive: acted with malicious activity;
      4. SOC Metrics
        1.  An effective threat-centric SOCconsists of deep expertise with cutting-edge technology, leading security intelligence data, and advanced analytics to detect and investigate threats with great speed, accuracy;
          1. Speed: Faster detection and targeted mitigation
          2. Focus: Higher fidelity reduces false positives and ensures proper containment and actionable recommendations for remediation;
          3. Accuracy: Continuous monitoring and investigation plus full packet capture illuminate security blind spots;
        2. Reason of metrics:
          1. To understand and identify the cybersecurity risk
          2. To measure the SOC effectiveness
          3. To optimize resource and investment allocation
        3. Typical metrics
          1. The mean TTD of the incident after its occurrence
          2. The mean time to contain the incident after its detection
          3. The mean time to mitigate the incident after its containment
          4. The number of incidents being detected, contained, and mitigated
          5. The percentage of the discovered incidents found using the plays in the SOC playbook
          6. The number of new plays added to the SOC playbook
          7. The number of zero-day attack detections
          8. The false positive or true positive detection rate
          9. The operational cost of running the SOC
        4. SOC that is advancing and maturing
      5. Challenge
        1. focuses precisely on a particular aspect: specific”
        2. “easily identifiable: measurable”
    12. Understanding the SOC WMS and automation
      1. SOC WMS Concepts
        1. syslog server makes it easier for the analyst to manipulate and review logs from numerous devices, but still difficult to correlate events with different formats; thus, SIEM emerges;
        2. WMS (Workflow Management System)
          1. software that tags and identifies an existing security event, tracks the event, and tracks the actions that are taken in dealing with those events, from detection to response to mitigation to ticketing closure;
          2. automates the remediation of a malicious action
          3. performs containment and eradication, but not identify incidents, collect evidence, or help with approvals;
            1. such as Swimlane dubs
          4. SOAR: security operations, analysis, and reporting can be used
          5. Information flow: SIEM and Ticketing System > Security WMS > Security Devices;
          6. Workflow Types
            1. Sequential: flow chart-based with one-to-one stage; does not step backward;
            2. State machine: progresses from state to state; can return to a previous point;
            3. Rules-driven: based on a sequential workflow. The rules dictate the progress of the workflow;
          7. Repeatable Tasks that WMS can automate
            1. Audit log collection and enrichment
            2. Look up user information
            3. Look up device information (IP, hostname)
            4. Notifications and alerts
            5. Threat intelligence
            6. Ticket management
            7. Callouts and escalations
      2. Incident Response Workflow
        1. ensure that all incident severity levels have a defined response process;
        2. severity of that incident may change during handling
        3. During incident response, consistent and timely reporting;
        4. Roles in Incident Response flow:
          1. Tier 1 analyst: Continuously monitors the alert queue; triages security alerts; monitors health of security sensors and endpoints; collects data and context necessary to initiate Tier 2 work;
          2. Incident response handler: Manages the incident; executes containment strategies and ensures that the incident response process is followed throughout; at times, may also communicate with the business to provide periodic updates
      3. SOC WMS Integration
        1. specifically in regard to remediation autonomously;
        2. receive security events and alerts information from the SIEM and then push information or commands to security devices;
        3. WMS Integration with SIEM
        4. WMS Integration Approaches
          1. RESTful API (Representation State Transfer)
            1. uses HTTP requests to get, put, post, and delete data;
            2. WMS may leverage RESTful API to update a corporate enterprise ticket management system
          2. Command line API
            1.  run directly from the command line
            2. to query an SIEM tool with the SOC in order to check on the status of a particular use case
          3. TAXII
            1. standardizes the automated exchange of cyber threat information.
      4. SOC Workflow Automation Example
        1. Goals of automating SOC processes and workflow
          1. Reduce the time to detection, containment, and remediation
          2. Reduce human errors
        2. WMS Products
          1. CyberSponse
          2. Resilient Systems
          3. Proofpoint Threat Response
          4. Swimland
      5. Challenge
    13. Describing the Incident Response Plan
      1. Incident Response Planning
      2. Incident Response Life Cycle (
        1. Typical phases
          1. Preparation (Education / documentation / R&R)
          2. Identification (monitoring)
          3. Analysis: prioritize subsequent activities
          4. Containment
            1. hardest and most important decision
          5. Eradication and Recovery
          6. Lessons Learned
            1. FMEA (failure mode and effects analysis): spreadsheet, to help practitioners anticipate what might go wrong with a product or process
          7. Reporting
      3. Incident Response Policy Elements (
        1. Mission, strategies, and goals
        2. Incident response approach
        3. Buy-in from senior managment
        4. Communication
        5. Metrics
        6. Review
        7. Organization missions
          1. Result -> lower dwell time
      4. Incident Attack Categories
        1. Incident classifications are typically based on incident severity
        2. Common attack vectors
          1. removable media
          2. Attrition: employs brute-force methods to compromise, degrade, or destroy systems, eg. DDoS
          3. Impersonation: replacement of something benign with something malicious—for example, spoofing, MITM attacks, rogue wireless APs, and SQL injection attacks
      5. Reference: US-CERT Incident Categories
        1. common set of terms and relationships schema that is defined by the US-CERT
        2. seven incident categories (CAT 0 to CAT 6) (
          1. CAT 0 – Exercise/Network Defense Testing
            1. approved activity testing of internal and external network defenses or responses;
          2. CAT 1 – Unauthorized Access
            1. individual will gain logical or physical access without permission;
          3. CAT 2 – Denial of Service (DoS)
            1. successfully prevents or impairs the normal authorized functionality;
          4. CAT 3 – Malicious Code
            1. Successful installation of malicious software
          5. CAT 4 – Improper Usage
            1. violation of acceptable computing use policies
          6. CAT 5 – Scans/Probes/Attempted Access
            1. seeks to access or identify an exploit
          7. CAT 6 – Investigation
            1. Unconfirmed incidents that are potentially malicious
      6. Regulatory Compliance Incident Response Requirements
        1. PCI DSS (Payment Card Industry – Data Security Standard)
          1. to protect cardholder data wherever it is processed, stored, or transmitted
      7. Challenge
    14. Appendix A – Describing the Computer Security Incident Response Team
      1. CSIRT Categories
        1. help ensure company, system, and data preservation by performing comprehensive investigations
        2. Investigate
        3. Mitigate
        4. Prevent
        5. Types
          1. Internal CSIRTs
          2. National CSIRTs
          3. Coordination centers: handling of incidents across various CSIRTs
          4. Analysis centers: synthesizing data from various sources to determine trends and patterns in incident activity
          5. Vendor teams:  handles reports of vulnerabilities in their software or hardware products
          6. Incident response providers:  services as a for-fee service
      2. CSIRT Framework (MCSR)
        1. Mission (what it sets out to do):
          1. eg. Responsible for global 24-hour monitoring, investigation, and response to cybersecurity incidents;
          2. eg. Engage in proactive threat assessment, mitigation planning, incident detection and response, incident trending with analysis, and the development of security architecture
        2. Constituency (serving Whom)
          1. serving targets and relationships
        3. Place in organization (what its roots look like)
          1. structure
        4. Relationship to others (who its peers are)
        5. Reference: Handbook for Computer Security Incident Response Teams (CSIRTs), Carnegie Mellon Software Engineering Institute
      3. CSIRT Incident Handling Services
        1. Reactive services:
          1. triggered by an event or request
          2. core component of CSIRT work, eg. incident handling service
        2. Proactive service:
          1.  provide assistance and information to help prepare, protect, and secure constituent systems in anticipation of attacks, problems;
          2. reduce the number of incidents in the future;
          3. eg. security audits or assessments service
        3. Definition of CSIRTs services:
        4. Incident handling service
          1. triage: single point of contact and the focal point for accepting, collecting, sorting, ordering, and passing on incoming information for the service
          2. handling: provides support and guidance that is related to suspected or confirmed computer security incidents, threats, and attacks
          3. announcement: tailored for the constituency in various formats to disclose details
          4. feedback: an interface for media requests
      4. Challenge
    15. Appendix B – Understanding the use of VERIS (Vocabulary for Event Recordings and Incident Sharing)
      1. VERIS Overview
        1. open format that helping organizations to collect incident-related information and to share the information anonymously and responsibly
        2. VERIS metrics as baselines for comparison
        3. 4 A’s: Actions, Actors, Assets, Attributes
      2. VERIS Incidents Structure
        1. documented using the VERIS schema
        2. structure with five main sections: better idea of the cause and severity
          1. Incident Tracking:
            1. general information about the incident
          2. Victim Demographics
            1. describes (but does not identify) the organization that is affected by the incident
            2.  compares different types of organizations or departments within a single organization
          3. Incident Description
            1. translates the incident narrative of “who did what to what (or whom) with what result” into a form that is more suitable for trending and analysis
            2.  translates the incident details into a form more suitable for trending and analysis
          4. Discovery and Response
            1.  focuses on the timeline of the events, how the incident was discovered, and lessons learned during the response and remediation process
          5. Impact Assessment
            1. leverages three perspectives of the impact in order to provide an understanding and measure of consequence that is associated with the incident
              1. the varieties of losses that are experienced
              2. estimate their magnitude
              3. capture a qualitative assessment of the overall effect on the organization
      3. VERIS 4 A’s
        1.  the minimum information that is required to adequately describe any incident or threat scenario
        2. Actors (Agents) (Refer.
          1. External actors
          2. Internal actors
          3. Partner actors: third party sharing a business relationship with the organization
        3. Actions
          1. actions describe what the threat actor did to cause or contribute to the incident
          2. every incident has at least one action
          3. Categories
            1. Malware
              1. Malware variety
              2. Malware vector
              3. Malware vulnerabilities
              4. Malware common name
            2. Hacking: all attempts to intentionally access or harm information assets without (or exceeding) authorization
              1. Hacking variety: Brute force / buffer overflow / MITM / SQL injection / DoS / path traversal
              2. Hacking vector: Command shell / VPN / Backdoor
            3. Social
              1. social tactics: phishing / scam
              2. social vector: email / IM / social media / website
            4. Misuse: use of entrusted organizational resources or privileges for any purpose contrary to what was intended
              1. Privilege abuse
              2. Data mishandling
              3. Email misuse
              4. Network misuse
              5. Illicit content
              6. Unapproved hardware
              7. Unapproved software
            5. Physical
            6. Error
            7. Environmental
        4. Assets: information assets that were compromised during the incident
          1. Network hardware
          2. Server
          3. User device
          4. Others
        5. Attributes
          1. security attributes of the identified assets that were compromised during the incident.
          2. confidentiality/possessionintegrity/authenticity,and availability/utility, which is an extension of the “C-I-A triad.”
      4. VERIS Records
        1.  VERIS record framework can be as simple or as complicated as you need it to be;
        2. records: documents the incidents in a standard way
        3. the ability of security analysts and investigators to ascertain the data needed to populate the various fields in the VERIS records
      5. VERIS Community Database (VCDB) (
        1. catalog security incidents in the public domain using the VERISframework
        2. promote data-driven decision making and evidence-based risk management in the information security community by creating a public repository of breach data in an open format
        3. GitHub repository (
        4. Refer:
      6. Verizon Data Breach Investigations Report and Cisco Annual Security Report
      7. Challenge
  4. Follow-ups
  5. Tools:
    1. Security Onion: Linux distribution with Log mgt, network security monitoring, IDS capabilities;
    2. Network analyst tools: Wireshark / Netwitness / OSSEC / NetFlow / Cisco Stealthwatch;
    3. Penetration testing tools: eg. Kali Linux with tools such as Metasploit Framework, Armitage, and SET (Social Engineer Toolkit)
    4. SIEM tools such as Splunk can help a SOC collect and normalize large amounts of disparate log data
    5. Capture session data by Bro
    6. ELSA can pivot directly to CapME!, which will decode the PCAP data associated with this particular TCP connection
      1. parses various event log to schema;
    7. threat intelligence platform called ThreatConnect
    8. Public Threat Awareness Resources:
      1. OWASP (Open Web Application Security Project).
      2. Spamhaus Project
      3. Alexa
      4. Farsight Security’s DNSDB
    9. Hackvertor is an online, community-based encoding tool by security Pros.
    10. submit hash value of file resulted in Sandbox testing;
    11. Useful blogs and feeds for security investigation:
    12. Reference: Crafting the InfoSec Playbook by Jeff Bollinger, Brandon Enright & Matthew Valites. ISBN: 978-1-491-94940-5.
    13. Karen Scarfone, Tim Grance, and Kelly Masone, Computer Security Incident Handling GuideNational Institute of Standards and Technology Special Publication SP 800-61 Revision 1, March 2008
  6. References
    1. detrimental
    2. vendor agnostic
    3. intrinsic
    4. vigilantly
    5. obfuscation
    6. disguising
    7. anomalous
  7. Exam experiences
    1. Network Intrusion Analysis
      1. HTTP and agent
    2. Incident Handling
    3. Computer Forensics
    4. retrospective security approach
    5. REGEX and search
    6. Wireshark commands
    7. Confidentiality definition in CVSS
    8. Computer Security Incident Handling Guide: NIST Special Publication 800-61  Revision 2
SECOPS – CCSA study log (210-255)