DOCSLIB.ORG

Threat Analytics Platform (TAP)

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Threat Analytics Platform (TAP) Threat Analytics Platform (TAP) Deployment Guide April 28, 2014 FireEye, Inc., 1440 McCarthy Blvd., Milpitas, CA 95035 | www.FireEye.com | +1 877.FIREEYE Information provided about third-party products does not imply any recommendation for use of that product. The information is provided as a guidelines only and is not guar- anteed to be accurate. © 2014 FireEye, Inc. All rights reserved. FireEye is a registered trademark of FireEye, Inc. All other brands, products, or service names are or may be trademarks or service marks of their respective owners. Use of this product and this document are subject to the terms of your license agreement with FireEye, Inc. Document version: v1.0B Contents Threat Analytics Platform (TAP) 1 Contents i About the Deployment Guide 1 Deployment Checklist 1 TAP Overview 2 TAP Architecture 2 Comm Broker Sender 4 Communications Broker Sender Configuration 4 Monitor Comm Broker Sender 5 Remove Comm Broker Sender 5 Troubleshoot Comm Broker Sender 5 Comm Broker Senders Traffic Management 6 Data Sources for TAP 8 Types of Log Data for TAP 8 Log Specifications for TAP 9 Log Aggregation System Configuration for TAP 9 Log Sources Supported by TAP 10 Cisco PIX and ASA Firewall Configuration 12 Juniper Secure Access Configuration 13 Linux Configuration 13 Rsyslog Configuration 13 Syslog-ng Configuration 14 McAfee Nitro Configuration 14 RSA Authentication Manager Configuration 15 Splunk Configuration 15 Symantec Endpoint Protection Configuration 16 Tomcat Configuration via Syslog 16 Trend Micro Control Manager Configuration 17 Appendix A. Windows Logging with NXLog 18 NXLog Installation and Configuration 18 Example nxlog.conf File 20 NXLog Troubleshooting 23 FireEye, Inc. Deployment Guide i Operating System Events 23 DNS Query Logs 23 DHCP Logs 24 Netlogin Debug Logs 24 IIS Logs 24 Process Creation Auditing 25 SQL Events 25 FireEye, Inc. Deployment Guide ii About the Deployment Guide This deployment guide is designed to assist you in configuring log sources and suc- cessfully transmitting them to your TAP instance. It contains information about the fol- lowing: l Overview of TAP including its architecture l Information about log sources for TAP l Comm Broker Sender configuration instructions Deployment Checklist Before deploying TAP, you must first contact FireEye Sales to obtain the proper license for Threat Analytics Platform (TAP). Your data sources will not be fully functional until you obtain this license. To contact the TAP team, including TAP Sales, e-mail to [email protected]. For more information on TAP, see the FireEye Threat Analytics Platform page on the FireEye website. FireEye, Inc. Deployment Guide 1 TAP Overview The FireEyeThreat Analytics Platform (TAP) is a security incident detection and res- olution tracking platform that identifies cyber threats and improves response by layering enterprise-generated event data with real-time threat intelligence from FireEye. TAP Overview TAP is a cloud-based application that: l Collects and indexes database, security, network, and endpoint events from your environment l Compares indicators in your events against FireEye intelligence in real time and generates alerts on hits l Applies both FireEye-defined rules and rules that you define to event data to gen- erate alerts l Provides an incident workflow for tracking both events associated with alerts and any events that you deem suspicious from investigation to remediation l Makes events available for efficient searching and pivoting l Provides visualizations of trending activity TAP Architecture Your TAP instance resides in two environments: your environment and a Virtual Private Cloud (VPC) within Amazon World Servies (AWS). Within your environment is one or more Communication Broker Senders that send log data to a Communications Broker FireEye, Inc. Deployment Guide 2 Receiver within TAP in the VPC. The Comm Broker Receiver and all other TAP components within the VPC are managed by the TAP Operations Team. TAP High-Level Architecture The data flow is as follows: l The Comm Broker sender listens receives log data in your environment and sends it to the Comm Broker Receiver in the VPC. For security purposes, all data in transit, including all metadata, is encrypted with Twofish with a 256-bit key. When data is transmitted over the WAN to the Communication Broker Receiver, it is double-encrypted with two layers of Twofish and 512 bits of key total. The Com- munication Broker Sender/Receiver combination never stores any customer data in clear text. l Log data is parsed according to the TAP taxonomy and then indexed to make it available for fast searches and pivoting. Log data that cannot be parsed is still indexed as raw messages. l Both FireEye-defined and customer defined rules are applied to the events and alerts generated if applicable. l FireEye Intelligence is also applied to all events in real-time and alerts generated for any hits. FireEye, Inc. Deployment Guide 3 Comm Broker Sender The Communications Broker (Comm Broker) Sender is an application runs on an Amazon Machine Image. It collects logs from within your Amazon Cloud environment and forwards them to the Communications Broker Receiver within your TAP architecture. Communications Broker Sender Configuration Before configuring the Comm Broker Sender, be sure that you have available the inform- ation provided by FireEye Product Support. To configure the Comm Broker Sender to send logs to the Comm Broker Receiver in your TAP VPC and to listen for log data: 1. Load the Amazon Machine Image (AMI) from the Amazon Marketplace. 2. Enter the key provided by FireEye Product Support. 3. Run the configuration script: ./ConfigSender.sh 4. Complete the post-install script as follows: l Welcome to the Threat Analytics Platform (TAP) Sender setup script. l Enter this Sender's identification number [38351]: (Enter the number provide by FireEye Support) l Enter symmetric key [NDd- jNjExZjhjZDAyY2IxMGU2YmU3MjI2MjUzN2MyMTgwODlj]: (Enter the number provide by FireEye Support) l Configure Sender listener addresses l Enter interface IP address that sender will listen on [0.0.0.0]: 0.0.0.0 (Hit Enter to select the default of 0.0.0.0) l Enter the protocol: [UDP] (Hit Enter to select the default of UDP or enter TCP) l Enter the port: [514] 514 (Hit Enter to select the default of 514) l Add another?: [no] (Hit Enter to continue; to add additional ports, enter yes.) l Listening configurations: 0.0.0.0\/514\/UDP (Hit Enter to select the default or modify if needed) l Configure Receivers' listener address and port l Enter interface IP address of receiver [ENTER]: (Enter the IP address provided by FireEye Product Support) l Enter the port: [443] 443 (Hit Enter to select the default) l Add another receiver?: [no] (Hit Enter to continue if you have only one receiver; enter yes if you have received FireEye, Inc. Deployment Guide 4 information from FireEye Support for additional Comm Broker Receivers) l List of receivers: (Hit Enter to select the default or make modifications as needed) 5. You should see the following messages: l Replacing senders in init file l tap-cbs stop/waiting l tap-cbs start/running, process 1448 l Sender has successfully been initialized Monitor Comm Broker Sender To monitor overall health, we recommend you monitor your systems in accordance with your corporate monitoring policy. Some areas to consider: l Network t/x and r/x are useful for watching trends in log traffic l CPU / memory / disk space l Monitor the host system if using virtualization for i/o performance As an application specific check, yhe following processes should appear with the sender has successfully connected to a receiver. Remove Comm Broker Sender You must remove all the tap-cbs files manually in order to reinstall a CB. l service tap-cbs stop l yum remove tap-cbs l rm /etc/init.d/tap-cbs l rmdir /opt/tap-cbs Troubleshoot Comm Broker Sender The following are potential actions for troubleshooting the Comm Broker Sender. Step1. Verify the process is running (e.g. ps aux | grep sender) FireEye, Inc. Deployment Guide 5 Step 2. Verify network connectivity between the Communications Broker and the cus- tomer instance (e.g. netstat –anp | grep sender) Step 3. Use tcpdump to verify the Communication Broker is receiving syslog traffic from log sources (e.g. tcpdump –ni eth1 –c 50 –s0 –A udp port 514) Alternatively, you can verify the Communication Broker is listening and receiving log traffic on the configured ports. Use the Netcat utility to send traffic from another device to the Communication Broker (e.g. echo -n "TEST TEST TEST" | nc -4u -w1 <ip address of sender> 514 ) Look for this traffic on the Communication Broker (e.g., tcpdump –ni eth1 –c 50 –s0 –A udp port 514 ) Comm Broker Senders Traffic Management To manage large streams of data both to the Comm Broker Sender and between the Comm Broker Sender and Comm Broker Receiver, TAP supports multiple options: l Multiple Comm Broker Senders l Load Balancers l Domain Name Servers (DNS) FireEye, Inc. Deployment Guide 6 TAP supports the use of multiple Comm Brokers Senders and Comm Broker Receivers. One Comm Broker Receiver can receive traffic from multiple Comm Broker Senders. Comm Broker Senders operate independently. Installing Comm Broker Senders closer to the log source conserves bandwidth. If your environment includes data centers that are regional, you could deploy one or more Comm Broker Senders within each data center. Comm Broker Senders can be deployed in arrays with load balancers for redundancy and load sharing. Load balancers can be used to detect when systems are in need of maintenance or repair, share the load across multiple systems, and provide redundancy. A Domain Name System (DNS) round robin can also be used to provide redundancy. Some system may not have the ability to syslog to a DNS and are limited to an IP des- tination only.
Load more

Recommended publications
  • Implementation of Centralized Logging and Log Analysis in Cloud Transition
    Implementation of Centralized Logging and Log Analysis in Cloud Transition Antti Vainio School of Science Thesis submitted for examination for the degree of Master of Science in Technology. Espoo 3.7.2018 Supervisor Prof. Jukka Suomela Advisor MSc Cyril de Vaumas Copyright ⃝c 2018 Antti Vainio Aalto University, P.O. BOX 11000, 00076 AALTO www.aalto.fi Abstract of the master’s thesis Author Antti Vainio Title Implementation of Centralized Logging and Log Analysis in Cloud Transition Degree programme Computer, Communication and Information Sciences Major Computer Science Code of major SCI3042 Supervisor Prof. Jukka Suomela Advisor MSc Cyril de Vaumas Date 3.7.2018 Number of pages 84 Language English Abstract Centralized logging can be used to collect log data from multiple log files on multiple separate server machines and transmit the data to a single centralized location. Log analysis on top of that can automatically process large amounts of logs for various different purposes including problem detection, troubleshooting, monitoring system performance, identifying security incidents, and understanding user behavior. As the volume of log data is growing when software systems, networks, and services grow in size, the log data located on multiple separate server machines can be difficult to manage. The traditional way of manually inspecting logs hasalso become too labor-intensive and error-prone when large amounts of log data need to be analyzed. Setting up centralized logging and automatic log analysis systems can be used to solve this problem. This thesis explains the concepts of log data, centralized logging, and log analysis, and also takes a look at existing software solutions to implement such a system.
    [Show full text]
  • Log-Management-Tenshi.Pdf
    Network Monitoring and Management Log Management Network Startup Resource Center www.ws.nsrc.org These materials are licensed under the Creative Commons Attribution-NonCommercial 4.0 International license (http://creativecommons.org/licenses/by-nc/4.0/) Log Management & Monitoring • Keep your logs in a secure place • Where they can be easily inspected • Watch your log file • They contain important information – Many things happen – Someone needs to review them – It’s not practical to do this manually Log Management & Monitoring On your routers and switches And, on your servers Log Management • Centralize and consolidate log files • Send all log messages from your routers, switches and servers to a single node – a log server. • All network hardware and UNIX/Linux servers can be monitored using some version of syslog (we use either syslog-ng or rsyslog for this workshop). • Windows can, also, use syslog with extra tools. • Save a copy of the logs locally, but, also, save them to a central log server. Syslog Basics Uses UDP protocol, port 514 Syslog messages have two attributes (in addition to the message itself): Facility Level Auth Security | Emergency (0) Authpriv User | Alert (1) Console Syslog | Critical (2) Cron UUCP | Error (3) Daemon Mail | Warning (4) Ftp Ntp | Notice (5) Kern News | Info (6) Lpr | Debug (7) Local0 ...Local7 | Centralized Logging Configuring Centralized Logging Cisco hardware – At a minimum: logging ip.of.logging.host Unix and Linux nodes – In syslogd.conf, or in rsyslog.conf, add: *.* @ip.of.log.host – Restart syslogd, rsyslog or syslog-ng Other equipment have similar options – Options to control facility and level Receiving Messages – syslog-ng • Identify the facility that the equipment is going to use to send its messages.
    [Show full text]
  • NXLOG Community Edition Reference Manual for V2.9.1716 I
    Ed. v2.9.1716 NXLOG Community Edition Reference Manual for v2.9.1716 i NXLOG Community Edition Reference Manual for v2.9.1716 Ed. v2.9.1716 Ed. v2.9.1716 NXLOG Community Edition Reference Manual for v2.9.1716 ii Copyright © 2009-2014 NXLog Ltd. Ed. v2.9.1716 NXLOG Community Edition Reference Manual for v2.9.1716 iii Contents 1 Introduction 1 1.1 Overview . .1 1.2 Features . .1 1.2.1 Multiplatform . .1 1.2.2 Modular architecture . .1 1.2.3 Client-server mode . .2 1.2.4 Log message sources and destinations . .2 1.2.5 Importance of security . .2 1.2.6 Scalable multi-threaded architecture . .2 1.2.7 High performance I/O . .2 1.2.8 Message buffering . .2 1.2.9 Prioritized processing . .3 1.2.10 Avoiding lost messages . .3 1.2.11 Apache-style configuration syntax . .3 1.2.12 Built-in config language . .3 1.2.13 Scheduled tasks . .3 1.2.14 Log rotation . .3 1.2.15 Different log message formats . .4 1.2.16 Advanced message processing capabilites . .4 1.2.17 Offline processing mode . .4 1.2.18 Character set and i18n support . .4 2 Installation and quickstart 5 2.1 Microsoft Windows . .5 2.2 GNU/Linux . .6 2.2.1 Installing from DEB packages (Debian, Ubuntu) . .6 2.2.2 Installing from RPM packages (CentOS, RedHat) . .6 2.2.3 Configuring nxlog on GNU/Linux . .6 Ed. v2.9.1716 NXLOG Community Edition Reference Manual for v2.9.1716 iv 3 Architecture and concepts 7 3.1 History .
    [Show full text]
  • Nxlog Community Edition Reference Manual
    NXLog Community Edition Reference Manual NXLog Ltd. Version 2.10.2150, November 2018 Table of Contents 1. Man Pages. 1 1.1. nxlog(8) . 1 1.2. nxlog-processor(8) . 3 2. Configuration . 5 2.1. General Directives . 5 2.2. Global Directives . 6 2.3. Common Module Directives. 7 2.4. Route Directives. 12 3. Language. 15 3.1. Types . 15 3.2. Expressions. 15 3.3. Statements . 24 3.4. Variables . 26 3.5. Statistical Counters . 26 3.6. Functions. 28 3.7. Procedures . 31 4. Extension Modules . 34 4.1. Character Set Conversion (xm_charconv) . 34 4.2. Delimiter-Separated Values (xm_csv) . 35 4.3. External Programs (xm_exec) . 39 4.4. File Operations (xm_fileop) . 41 4.5. GELF (xm_gelf) . 44 4.6. JSON (xm_json). 48 4.7. Key-Value Pairs (xm_kvp) . 51 4.8. Multi-Line Parser (xm_multiline) . 60 4.9. Perl (xm_perl) . 68 4.10. Syslog (xm_syslog) . 71 4.11. WTMP (xm_wtmp) . 83 4.12. XML (xm_xml). 84 5. Input Modules . 88 5.1. Fields . 88 5.2. DBI (im_dbi) . 88 5.3. External Programs (im_exec) . 89 5.4. Files (im_file) . 90 5.5. Internal (im_internal). 93 5.6. Kernel (im_kernel) . 95 5.7. Mark (im_mark) . 96 5.8. EventLog for Windows XP/2000/2003 (im_mseventlog). 97 5.9. EventLog for Windows 2008/Vista and Later (im_msvistalog) . 100 5.10. Null (im_null) . 105 5.11. TLS/SSL (im_ssl) . 105 5.12. TCP (im_tcp) . 107 5.13. UDP (im_udp) . 108 5.14. Unix Domain Sockets (im_uds) . 109 6. Processor Modules . 111 6.1. Blocker (pm_blocker) . ..
    [Show full text]
  • Fedora 16 System Administrator's Guide
    Fedora 16 System Administrator's Guide Deployment, Configuration, and Administration of Fedora 16 Jaromír Hradílek Douglas Silas Martin Prpič Eva Kopalová Eliška Slobodová Tomáš Čapek Petr Kovář Miroslav Svoboda System Administrator's Guide John Ha David O'Brien Michael Hideo Don Domingo Fedora 16 System Administrator's Guide Deployment, Configuration, and Administration of Fedora 16 Edition 1 Author Jaromír Hradílek [email protected] Author Douglas Silas [email protected] Author Martin Prpič [email protected] Author Eva Kopalová [email protected] Author Eliška Slobodová [email protected] Author Tomáš Čapek [email protected] Author Petr Kovář [email protected] Author Miroslav Svoboda [email protected] Author John Ha Author David O'Brien Author Michael Hideo Author Don Domingo Copyright © 2011 Red Hat, Inc. and others. The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. The original authors of this document, and Red Hat, designate the Fedora Project as the "Attribution Party" for purposes of CC-BY-SA. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version. Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law. Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, MetaMatrix, Fedora, the Infinity Logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
    [Show full text]
  • Ubuntu Server Guide Basic Installation Preparing to Install
    Ubuntu Server Guide Welcome to the Ubuntu Server Guide! This site includes information on using Ubuntu Server for the latest LTS release, Ubuntu 20.04 LTS (Focal Fossa). For an offline version as well as versions for previous releases see below. Improving the Documentation If you find any errors or have suggestions for improvements to pages, please use the link at thebottomof each topic titled: “Help improve this document in the forum.” This link will take you to the Server Discourse forum for the specific page you are viewing. There you can share your comments or let us know aboutbugs with any page. PDFs and Previous Releases Below are links to the previous Ubuntu Server release server guides as well as an offline copy of the current version of this site: Ubuntu 20.04 LTS (Focal Fossa): PDF Ubuntu 18.04 LTS (Bionic Beaver): Web and PDF Ubuntu 16.04 LTS (Xenial Xerus): Web and PDF Support There are a couple of different ways that the Ubuntu Server edition is supported: commercial support and community support. The main commercial support (and development funding) is available from Canonical, Ltd. They supply reasonably- priced support contracts on a per desktop or per-server basis. For more information see the Ubuntu Advantage page. Community support is also provided by dedicated individuals and companies that wish to make Ubuntu the best distribution possible. Support is provided through multiple mailing lists, IRC channels, forums, blogs, wikis, etc. The large amount of information available can be overwhelming, but a good search engine query can usually provide an answer to your questions.
    [Show full text]
  • Facing the Challenge(S) of Windows Logs Collection to Leverage Valuable Iocs
    Facing the challenge(s) of Windows logs collection to leverage valuable IOCs . Michel de Crevoisier Security Analyst, Radar Cyber Security 15.10.2019, Berne © RadarServices // Classification: Public The five challenges © RadarServices // Classification: Public #1 High diversity of log sources Server Microsoft 3rd party Built-in roles software software Advanced Threat ADFS Application Analytics (ATA) Ivanti software Certification authority Exchange PowerShell Kaspersky DHCP server Skype Security DNS server SQL Server Veeam Backup System IIS web server SYSMON […] […] NPS Radius Defender © RadarServices // Classification: Public 3 #2 Different log extensions EVTX ETL TXT (standard Windows logs (analytical logs, like DNS (IIS, NPS, DHCP, in XML format) Server or PowerShell) PowerShell Transcript, former DNS logs) © RadarServices // Classification: Public 4 #3 Multiple architectural approaches Access method / Protocol (MS-EVEN6, RPC, WMI,…) Push vs Pull Agent vs Agentless Intermediate collector VS Direct sending to receiver Central file store vs Shared folder Managed agent VS Unmanaged agent © RadarServices // Classification: Public 5 #4 Disabled and restrictive event logs • Protected users (if configured, on DCs only) Valuable event • LSA (Local Security Authority) logs disabled • IIS web server • DNS client Event logs with • SMB server restrictive • SMB client access • IIS web server © RadarServices // Classification: Public 6 6 #5 Operational constraints Security Data exchange Performance Configuration Environment • Avoid usage of • Data
    [Show full text]
  • Using Nxlog with Elasticsearch and Kibana I
    Using NXLog with Elasticsearch and Kibana i Using NXLog with Elasticsearch and Kibana Using NXLog with Elasticsearch and Kibana ii Contents 1 Setting up Elasticsearch and Kibana 1 1.1 Installing Elasticsearch . .1 1.2 Installing Kibana . .1 2 Loading data into Elasticsearch with NXLog2 2.1 Loading data with om_elasticsearch . .2 2.2 Loading data with om_http . .4 2.3 Using Logstash . .5 Using NXLog with Elasticsearch and Kibana 1 / 6 Elasticsearch coupled with the Kibana frontend has become quite popular recently as a low-cost centralized log monitoring solution. This is commonly referred to as the ELK stack comprised of Elasticsearch, Logstash and Kibana. While Logstash is a great piece of software it has some disadvantages compared to NXLog: • Logstash is written in ruby and requires Java to run. Besides being a lot more hungry on system resources, many system administrators would rather not take the hassle of deploying the Java runtime onto their production servers and needing take care of the Java security updates. • The Eventlog plugin in Logstash pulls the eventlog data through the Windows WMI interface which incurs a significant performance penalty. NXLog hooks directly into the Windows EventLog API natively and can collect logs from our highly loaded Domain Controllers also. • It’s just one more piece of software to take care about. NXLog is a small and efficient log collector that can be set up to securely and reliably centralize event data from Windows and Unix platforms. As such, NXLog is recommended by many ELK users as the log collector of choice for Windows and Linux.
    [Show full text]
  • An Exploratory Semantic Analysis of Logging Questions
    Received: Added at production Revised: Added at production Accepted: Added at production DOI: xxx/xxxx An Exploratory Semantic Analysis of Logging Questions Harshit Gujral*1 | Sangeeta Lal2 | Heng Li3 1Department of Computer Science Engineering and Information Abstract Technology, Jaypee Institute of Information Technology, Noida, India. Logging is an integral part of software development. Software practitioners often face issues Email: [email protected] in software logging, and they post these issues on Q&A websites to take suggestions from 2Lecture Data Science, School of Computing and Mathematics, Keele the experts. In this study, we perform a three-level empirical analysis of logging questions University, Keele, United Kingdom. posted on six popular technical Q&A websites, namely Stack Overflow (SO), Serverfault Email: [email protected] 3Department of Computer and Software (SF), Superuser (SU), Database Administrators (DB), Software Engineering (SE), and Engineering, Polytechnique Montréal, Android Enthusiasts (AE). The findings show that logging issues are prevalent across var- Montréal, Canada. Email: [email protected] ious domains, e.g., database, networks, and mobile computing, and software practitioners from different domains face different logging issues. The semantic analysis of logging ques- Correspondence *Corresponding author. tions using Latent Dirichlet Allocation (LDA) reveals trends of several existing and new logging topics, such as logging conversion pattern, android device logging, and database logging. In addition, we observe specific logging topics for each website: DB (Log shipping, Log file growing/shrinking), SU (Event Log, Syslog configuration), SF (Log analysis, Sys- log configuration), AE (App Install, Usage tracking), SE (Client server logging, Exception logging), and SO (Log file creation/deletion, Android Emulator Logging, Logger class of log4j).
    [Show full text]
  • Linux and Open Source for (Almost) Zero Cost PCI Compliance
    Linux and Open Source for (Almost) Zero Cost PCI Compliance Rafeeq Rehman 2 Some Introductory Notes ¡ Payment Card Industry (PCI) standard is not a government regulaon. ¡ Who needs to comply with PCI? ¡ Twelve major requirements covering policy, processes, and technology to protect Credit Card Data. ¡ What is Credit Card Data? ¡ Few Clarificaons ¡ Payment Card Industry (PCI) requires some tasks to be performed by external vendors depending upon merchant level. There is no other way around, unfortunately. ¡ Open Source soluCons do need people. That is why it is almost free but not totally free. 9/10/11 3 What the Auditors Look For? ¡ Is PCI just a checklist? ¡ Are auditors genuinely interested in securing the PCI data? ¡ Does it maer if you use an open source or commercial product to meet PCI requirements? ¡ What if you meet PCI requirements while improving security and spending less money? 9/10/11 4 Is it viable to use Open Source for PCI Compliance? ¡ Is there a real company who uses Open Source soQware to achieve PCI compliance? Is it even possible? ¡ PCI 2.0 focuses more on Risk based approach. ¡ PCI (or any compliance) is boring! Make it interesCng by using Open Source. 9/10/11 5 PCI Biggest Expenses 1. Log Management (Storage and archiving, Monitoring and Alerng) 2. Vulnerability Scanning 3. Network Firewalls and Network Segmentaon 4. Intrusion DetecCon System 5. EncrypCon for data-at-rest 6. File Integrity Monitoring 7. IdenCty Management (Password controls, Two factor for remote access, Role based access) 9/10/11 6 AddiConal PCI
    [Show full text]
  • Red Hat Openstack Platform 16.1 Logging, Monitoring, and Troubleshooting Guide
    Red Hat OpenStack Platform 16.1 Logging, Monitoring, and Troubleshooting Guide An In-Depth Guide to OpenStack Logging, Monitoring, and Troubleshooting Last Updated: 2021-05-13 Red Hat OpenStack Platform 16.1 Logging, Monitoring, and Troubleshooting Guide An In-Depth Guide to OpenStack Logging, Monitoring, and Troubleshooting OpenStack Team [email protected] Legal Notice Copyright © 2021 Red Hat, Inc. The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/ . In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version. Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law. Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries. Linux ® is the registered trademark of Linus Torvalds in the United States and other countries. Java ® is a registered trademark of Oracle and/or its affiliates. XFS ® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries. MySQL ® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
    [Show full text]
  • Analysis and Comparison of Log Shipment Solutions at AWS S3 for Windows 10
    Department of Information Engineering and Computer Science Master in Computer Science 2020-2021 Final thesis Analysis and comparison of Log Shipment solutions at AWS S3 for Windows 10. Francisco Manuel Colmenar Lamas i SUMMARY A fundamental aspect that every company must address to start building its security infrastructure is visibil- ity. Increasing a company’s visibility raises the quality and effectiveness of all other existing security solutions. The objective was to implement an endpoint log forwarding solution for the Windows 10 devices of the com- pany About You. To accomplish the objective, several concepts and knowledge in the scope of log management solutions were studied, as well as the use of AmazonWeb Services (AWS) dedicated to these activities. After analyzing the different solutions, Kinesis Windows Agent was chosen to implement the endpoint log shipment solution. Because it provides a serverless architecture, where the agent sends logs from the endpoints to Kinesis Firehose. In addition, it does not require any heavy-weight dependencies and its configuration is straightforward. Also, since Kinesis Firehose is an AWS managed service, there is no need to handle the scaling or fault tolerance issues common in a client-server architecture and it integrates seamlessly with S3. Regarding the implementation, the code for the installation and maintenance of the Kinesis Windows Agent was mainly developed in Powershell scripts triggered remotely using Ninjarmm. And the AWS infrastructure code required for this project was developed using Terraform. In addition, through Gitlab’s CI/CD pipeline, AWS resources are automatically updated if the code is modified. As a conclusion, the deployment of the Kinesis agent for Windows on all employee Windows devices was a success.
    [Show full text]