A typical network audit comprises of a detailed architecture review, a thorough technical assessment for configurations for all critical components and cyber security review.
Network Security Audit is a fundamental part of any I.T Security standard; with security dynamics within your organization ever changing, new threats materializing, risks exposure increasing, new applications provisioned with inherent security concerns, auditing becomes an integral process to ensure risks are contained and controlled.
Frequent Network Security Audit allows your organization to periodically assess and review the security posture of a certain environments; identifying key risk factors, categorizing them based on priority and severity level, quantifying the risk and placing an action on the risk. Risk management process is tightly integrated with our Network Security Audit service.
With qualified Information Systems Auditors, our Network Security Audit service is based on;
-- Audit Scope and Statement of Work – Identifies which environment the audit will take place
-- Identification of Risks within the particular environment – information gathering and assessment
-- Categorization of Risk based on severity
-- Qauntify the Risks based on probability and likelihood
-- Business Impact Analysis
-- Risk Management recommendation – mitigate, acceptance, transference and action for residual risk
-- Audit reporting and communication
Network Security Audits can be requested in the following areas;
-- Network Firewalls
-- Intrusion Prevention System
-- Web Application Security
-- Database Security
-- Network and System Management Security
-- Infrastructure hardening
Firewall audits are getting a lot of coverage these days thanks to standards such as SOX, PCI-DSS, and HIPAA. Even if you don’t need to comply with any of those standards – yet – business relationships with partners or customers may require you to show that your network is secure.
However, beyond compliance requirements, firewall audits are best practice for a very good reason. They increase your chances of catching weaknesses in your network security posture and finding places your policies need to be adapted. They also help prove you have been doing your due diligence in reviewing your security controls and policy controls, should you ever need to respond to a lawsuit, breach or regulatory issue that call your security standards into question.
Two of the most important aspects of conducting a firewall audit are to review the change process and the rule base. If you are tasked with pre-auditing your firewall before the audit team arrives, or if it is your job to audit the firewall, here are some of the main technical details you’ll need to check.
1) Auditing the Change Process The first technical step in a firewall audit is normally an examination of the firewall change process. The goal of this step is to make sure that requested changes were properly approved, implemented and documented. You can accomplish this in a few different ways – depending on whether you have a tool to assist you or you are doing it manually. You will need to pull, at random, around 10 change requests since the last audit. The basic questions you should be asking when you audit a firewall change are: • Is the requester documented, and is s/he authorized to make firewall change requests? • Is the business reason for the change documented? • Are there proper reviewer and approval signatures (electronic or physical)? • Were the approvals recorded before the change was implemented? • Are the approvers all authorized to approve firewall changes (you will need to ask for a list of authorized individuals)? • Are the changes well documented in the change ticket? • Is there documentation of risk analysis for each change? • Is there documentation of the change window and/or install date for each change? • Is there an expiration date for the change? If you are doing this manually, the first thing you need to do is match each of the changes up with a firewall device and with a policy. Now match the change requests up with the firewall rule(s) that implemented the requested traffic. Already stumped? Then you know where you need to improve. The comment on each rule should have at least two pieces of data: the change ID of the request and the initials of the engineer who implemented the change. Automation tools are widely available, and because of the sheer number of rules that most modern firewalls tend to manage, are highly recommended to aid you in the audit process., and offer significantly more visibility into and control over your rule base. For example, they show you who added the rule and when, as well as if s/he added anything else to the policy at the same time. They also enable you to put the change ticket number in the comment field, so that the rule will have a hyperlink back to the change ticket to simplify looking up the audit trail. You can even run a rule history report over time to see how this rule has changed with other change tickets since it was implemented. Solutions with more mature change management capabilities will show the rule request along with audit signoff, risk analysis, and implementation into the rule-base, so that the whole lifecycle from request to implementation is documented and auditable. 2) Auditing the Firewall Rule Base The second technical step in an audit is usually a review of the firewall rule base (also called a policy). The methodology for this step varies widely among auditors because it has traditionally been difficult to do and heavily technology-dependent. For each of these questions you should have a ranking based on the type of firewall and its placement in your infrastructure. For example, a firewall not connected to the Internet does not have the same risk as one that is connected to the Internet; internal firewalls tend to be more permissive than external firewalls. The first questions that should be asked about the rule base are related to basic policy maintenance and good design practices that grant minimal access for each device. To answer these questions, you need to look at each rule in your rule base and as well as a year’s worth of logs, which will tell you which rules are being used. This has always been a lengthy manual process until recently, with the arrival of tools that can be used to answer these questions programmatically and automatically. • How many rules does the policy have? How many did it have at last audit? Last year? • Are there any uncommented rules? • Are there any redundant rules that should be removed? • Are there any rules that are no longer used? • Are there any services in the rules that are no longer used? • Are there any groups or networks in the rules that are no longer used? • Are there any firewall rules with ANY in three fields (source, destination, service/protocol) and a permissive action? • Are there any rules with ANY in two fields and a permissive action? • Are there any rules with ANY in one field and a permissive action? • Are there any overly permissive rules: rules with more than 1000 IP addresses allowed in the source or destination? (You might want a number other than 1000, like 10,000, or 500) The second list of questions that should be asked about a rule base are related to risk and compliance. These rules are more technically challenging to answer. You must understand the technology of your firewall to understand what traffic is actually passed by each rule, and if there is a group of services called “allowed services,” then which ports and protocols actually pass though that rule. • Are there any rules that violate our corporate security policy? • Are there any rules that allow risky services inbound from the Internet? While you may have a different list of what is considered “risky” for your company, most start with protocols that pass login credentials in the clear like telnet, ftp, pop, imap, http, netbios, etc. • Are there any rules that allow risky services outbound to the Internet? • Are there any rules that allow direct traffic from the Internet to the internal network (not the DMZ)? • Are there any rules that allow traffic from the Internet to sensitive servers, networks, devices or databases? If you take the time to master those two processes you will find that it is much easier to pass firewall audits. Having responded to hundreds of firewall audits, I’m a huge fan of automating this process as much and as deeply as possible. That provides the information administrators need to answer difficult audit questions. However, if you are tasked with auditing a large set of firewalls on an ongoing basis – or even a couple of firewalls with large and unwieldy rule bases - the time and money saved combined with eliminating the margin for error that exists with any attacking any granular, data-intensive, audit manually makes it worth the cost and effort. If automation is not an option, then addressing these two areas are absolutely essential to maintaining the health and effectiveness of your firewall policies.
Server audit performs a detailed security check for the following items
--- System Configuration
--- System Accounts Policy
--- Audit Policy Settings
--- Registry Key Values
--- User Accounts Defined On Your System
--- Local Groups and their Members
--- Global Groups and their Members
--- Last Logons, 30 Days and Older
--- Passwords, 30 Days and Older
--- Passwords that Never Expire
--- Invalid Logon Attempts Greater than 3
--- Users not Allowed to Change Passwords
--- Accounts with Expiry Date
--- Disabled Accounts
--- Rights and Privileges (Users, Groups)
--- Trusted and Trusting Domains
--- Local Accounts
--- Servers and Workstations
--- RAS Privileges
--- Services and Drivers on the Machine
--- Server Roles and Features
--- Task Scheduler Settings
--- Security Updates, Patches and Hot-Fixes
--- Products Installed
--- Current Network Connections
--- Domain Controllers in the Domain
--- Logical Drives
--- Network Shares
--- Home Directories, Logon Scripts, Profiles
--- File Permissions and Auditing
Patching is the process of repairing system vulnerabilities which are discovered after the infrastructure components have been released on the market. Patches apply to many different parts of an information system which include operating systems, servers, routers, desktops, email clients, office suites, mobile devices, firewalls, and many other components that exist within the network infrastructure. The number of patches which are required on a consistent basis can be overwhelming. This is why it is necessary to devise a patch management process to ensure the proper preventive measures are taken against potential threats.The methods which are used for patch management will vary slightly according to the infrastructure design for each company information system. That said here is a general description of how patch management is typically deployed.
Most companies with large infrastructures implement automated patch management systems which reduce the requirements for manpower that would otherwise be needed for manual implementation. Other companies choose to outsource patch management to a qualified company which will perform this service from a remote location.
An automated patch management system involves the installation of a client agent that allows network administrators to control patch distribution from a web-based interface. This type of system allows network administrators to configure the settings for patch distribution and generate log reports to check the status of patches. Patch distribution can also be set at different levels within the infrastructure to cover different applications and devices which are used to access data and information.
Due to the fact that the components which make up network infrastructure and information systems are not perfect when they are released on the market makes patch distribution all that much more important. patch management is preventative and the number of vulnerabilities discovered over an extended period of time can seriously compromise the integrity and security of information. In the event there is a window of vulnerability, a solid patch management system means a network is being consistently monitored. This allows immediate action to be taken if a patch has yet to be released when a vulnerability is discovered. The importance here is the prevention of what is known as a ‘Zero Day Attack’ which is an exploit that can occur while a patch is in the process of being produced to repair the vulnerability. Attacks such as these can be minor or they can be as malicious as taking down an entire company network. Patch management is very critical to business operations however it also tends to be considered a responsibility of the IT department. While this is partially true patch management within an organization’s infrastructure cannot be successful without the understanding and support of the senior management. Instead of waiting for the issue to be addressed when a problem occurs it is important to implement and plan for patch management in advance. The key concerns for many companies are in the number of patches and the manpower needed to deploy them. However, new technologies along with enterprises which offer patch management services have made patch management implementation and distribution easier and more cost effective.
A common method of malware delivery is via an exploit kit. An exploit kit is a scalable software package, which allows modules to be removed, added or updated with new exploits. These kits typically come bundled with a management console, vulnerabilities for different applications and functions that allow an attacker to launch attacks.
As new vulnerabilities are identified, exploit modules are created which take advantage of the new exposures. Unpatched applications such as Adobe Flash, Adobe Acrobat and Microsoft Internet Explorer are commonly sought out by attackers. When activated, the kit identifies any vulnerabilities in the software installed on the targeted system.
Patching is an effective method of mitigating this risk. According to the 2017 Verizon Data Breach Investigations Report, “Having a good patch process is a fundamental security practice.” But patching can be a pain due to the sheer number of updates available. If you have multiple system architectures within your organization, the number of patches increases exponentially, which also increases your cyber risk.
When speaking with customers about the importance of patching, I’ve often heard the following two questions:
With so many patches available, how do we prioritize them?
How can we keep our organization up-to-date when vendors continue to release new updates?
A review of the current state of your security architecture should form part of your ongoing security improvement initiatives. A security architecture includes the unified and integrated design, implementation, and operation of security practices across your organisation. This will enable you to formulate a plan to manage risks, maintain compliance with external regulations and contractual mandates, or at least align to industry best practice
The Assessment includes: • an interactive workshop to assess your current and desired state • the option to choose from a selection of security assessments that assess the security landscape • recommendations for improvement • the development of a security roadmap based on business and technology initiatives
Our Security Architecture Assessment is a flexible engagement through which we undertake a detailed assessment of your security architecture, from policies to technical controls. Delivered through a choice of three service models, the outcome is a specific set of recommendations that allow you to apply your resources and controls in the most effective way to protect key assets. Combined with a remediation roadmap, the results can be used to build a budget and resource plan, or simply align to an existing strategy for confirmation and reassurance.
Valency Networks is a very agile, friendly and fun loving atmosphere and yet we maintain a cutting edge technical vibrant work environment.