Information Technology, Control, Audit and Security Experience

Static code analysis, is a method in computer program debugging that is done by examining the code without actually executing the program. The process provides an understanding of the code structure, and can help to ensure that the code adheres to laid down standards. Automated tools can assist programmers and developers and auditors in carrying out static analysis. The process of scrutinising code by visual inspection alone (by looking at a printout, for example), without the assistance of automated tools, is sometimes called program understanding or program comprehension. This post will look at the techniques of static code analysis in order to understand the concept of static code analysis

Yasca which is an acronym for "Yet Another Source Code Analyzer" is an open source program which looks for security vulnerabilities, code-quality, performance, and conformance to best practices in program source code. It leverages external open source programs, such as FindBugs, PMD, JLint, JavaScript Lint, PHPLint, Cppcheck, ClamAV, Pixy, and RATS to scan specific file types. It also contains many custom scanners developed for Yasca. It is a command-line tool that generates reports in HTML, CSV, XML, MySQL, SQLite, and other formats. Languages Scanned with Yasca Yasca has at least one scanner for each of the following file types: DotNET (VB.NET, C#, ASP.NET), ASP, C/C++, COBOL, ColdFusion, CSS, HTML Java,JavaScript, Perl, PHP, Python, Raw HTTP Traffic, Visual Basic In this post we will be looking at how to install and use Yasca source code analyser. To understand more about source code analyzers click on this link to my previous post on  Understanding Static Cod...

SSLscan is another type of port scanner similar to NMAP. However its objective is to scan SSL ports to determine what security protocols or ciphers supported and/or preferred. In this blog post we will be looking at how to access and use SSLscan. It is very useful when it comes to testing security protocols accepted by sensitive servers. Its important to note that the accepted security protocols of present is TLSv1.1 and above. The most preferred for utmost security is now TLSv1.2 upwards. Lets get busy

Every HTTPS connection begins with what is called  a HANDSHAKE which is the negotiation between a client and server detailing and agreeing on how they will communicate. The handshake determines the following: What cipher suite to be used to encrypt the communications, Serer verification by Client, Clients verification by Server Lets now go through the 11 steps to establish this secure connection

POODLE stands for P adding O racle O n D owngraded L egacy E ncryption. It was a significant  security vulnerability where SSL v3.0 can be attacked and the encrypted data between the computers and servers can be potentially intercepted and decrypted. Too much tech grammar? ... Dont worry as I will demystify this as easy as possible to you. Just stay with me.

PCI security standard council has stated in their official site* that: "30 June 2018 is the deadline for disabling SSL/early TLS and implementing a more secure encryption protocol – TLS 1.1 or higher (TLS v1.2 is strongly encouraged) in order to meet the PCI Data Security Standard (PCI DSS) for safeguarding payment data." Is your organisation ready for this change ?