Detect perimeter changes before hackers detect them!
If your network perimeter changes unexpectedly, that's unlikely to be a good thing. What is the cause?
- Unauthorised change?
- Steve in networking misconfigured a firewall?
- Hacker's shell?
- Shadow IT?
- Rogue device?
- Post-M&A networking headaches?
Musang is a software tool for automatically assessing the security of Oracle Databases.
Musang's design ensures:
- Accuracy: The testing module has full and clear visibility of database configuration.
- Efficiency: Configuration is easy, and reports are concise, focusing on the critical aspects.
- Designed AND IMPLEMENTED by Subject Matter Experts: Unlike so many other security software packages, Musang was not only conceived by Security experts, it was also fully designed and implemented by Oracle Database security subject matter experts, with 10 years of experience behind them.
- Speed: The bottleneck is more likely to be network bandwidth rather than processing time.
- Compliance Testing: Tests covered ensure most popular audit concerns are covered - HIPPA, PCI-DSS, ISO 27001, etc
Musang interrogates Oracle Databases in a fast and accurate way. There are many Oracle Database vulnerabilities known to the security community that arise from misconfigurations and DBA oversights. Musang tests for these vulnerabilities in a unique way that permits accuracy and efficiency.
Partial Screen Shots
|Musang login||Test progress||Test report|
How Does Musang Work?
Musang relies on authenticated methods to test vulnerability and the authenticated part is the most critical aspect. Being authenticated, having effectively read-only DBA access, means Musang can "see" clearly all aspects of database configuration. And this also means radically fewer false positives. In most cases there will be no false positives at all.
The authenticated nature of the testing plus the contextual testing (see next section) implemented by Oracle Database security experts ensures radically fewer false positives compared with unauthenticated, "blind" scanners.
Unlike other scanners, Musang takes into account the effect that different server settings can have on each other. For example: weak passwords by themselves constitutes a vulnerability, but what if the accounts are lock or expired? In this case a vulnerability is not flagged by Musang, however both items of configuration are itemised as "Informational" by the testing engine.
False positives are bad for business. They're bad for the information security practice in a business, and they're consequently bad for operations, application developers, and management. They're a time and resources sink hole.
The worst aspect of false positives is the effect they have on trust. Security Managers and Analysts want to be able to trust their tools to automatically find vulnerability. If there is no trust, it makes integration with other departments very tough. Security Managers need to have confidence when they report on the progress of their vulnerability management programs.
With Musang - the lack of false positives and accurate output finally allows confidence in the automation of vulnerability assessment.
Musang is a Python/Django web-based project currently at version 1.4.
Currently Oracle Database 12c, 11g and 10g are supported targets.
The tests library has been compiled based on the requirements of most businesses' Security Standards for Oracle Database. There are several public sources of Oracle Database security configuration items (e.g. the CIS Benchmarks) and these tests are all included as well as some important tests included by the development team based on their experiences in security testing and security incidents. In summary: no stone has been left unturned.
As a high level description, the following tests are covered:
- User account profile tests
- Informational config dumps: these are not vulnerability tests per say, they give DBAs/devs information which may well be of interest from a security perspective. The information that is dumped may well reveal further vulnerabilities on investigation, or it might just typically be of interest for DBAs, developers, or Security experts
- TNS listener poisoning
- Auditing and logging configuration tests
- Passwords (password hashes are viewable for users in a username:password format, suitable for crackers such as JTR, Hashcat, etc)
- Obvious weak and default passwords
- Other TNS listener critical tests
- User account authentication settings
- Roles and privileges (the full dump of privileges is made available with some suspect items highlighted)
- User account trust relationships are investigated
- Database links are identified (and highlighted) and tested
Latest Blog Post
Fintechs and Security - Part 4
April 12, 2020, 7:15 p.m.
Notice "Logging" is used here, not "SIEM". With use of "SIEM", there is often a mental leap, or stumble, towards a commercial solution. But there doesn't necessarily need to be a commercial solution. This post invites the reader to take a step back from the precipice of engaging with vendors, and check first if that journey is one you want to make.
Unfortunately, in 2020, it is still the case that many fintechs are doing one of two things:
The process HLD takes into risks from threat modelling (and maybe other sources), and another input from compliance requirements (maybe security standards and legal requirements), and uses the requirements from the HLD to drive the LLD. The LLD will call out the use cases and volume requirements that satisfy the HLD requirements - but importantly, it does not cover the technological solution. That comes later.
Security De-engineering, published by Taylor Francis, covers ubiquitous problems in information security and offers a solution in the final chapter
Areas covered: Penetration testing, Hackers, CASEs (Checklists and Standards Evangelists), IDS, Cloud Security, jobs in security, Identity Management, and organisational elements.