Top Programming Languages in 2017

Computer Languages - SeniorDBA

What computer languages will be the most popular in 2017? This is actually a relevant question for new and long-time programmers if they want to make sure they are learning and using a popular (an potenially marketable) computer language.

In this article byMahesh Chand, we see his research into what the most popular languages are for now:

The most in-demand programming language can be directly proportional to the number of jobs available in the market. Based on the data gathered from Indeed, a report published on CodingDojo lists the languages, given below, as the most in-demand in 2016:

  • SQL
  • Java
  • JavaScript
  • C#
  • Python
  • C++
  • PHP
  • Objective-C/Swift
  • Ruby/Ruby on Rails

Business Insider ranks the languages, given below, as the most in-demand.

  • Java
  • PHP
  • Perl
  • C
  • Objective-C
  • JavaScript
  • Visual Basic
  • Ruby
  • Python
  • CSS
  • R

5 Tips for Small Business IT Security


Running a small business can be stressful enough without worrying about technology issues and dealing with system security. It can be difficult to know where to start and what steps you should take with a limited budget and a small team of professionals.

These basic guidelines should help you understand where to start and what steps need to be taken.

  1. Manage risk – Start by asking what information is most important to your business and what steps need to be taken to protect that information. Think what would damage your business if it was available to the public, like business logic or customer lists. What can you do today to protect that information?
  2. Training – Determine the strengths and weaknesses of your team. If you don’t have an internal resource, hire someone to educate your team on the correct way to protect your critical data and how to identify common attacks, like email phishing and malware attacks. Create policies about social media and make sure your team understands how to use it in a secure way to protect the company.
  3. System Updates – It takes considerable effort to keep yourself educated about new cybersecurity threats. It also takes effort to keep your computer systems updated to address the latest threats. Spend some time making sure updates are applied to user systems.
  4. Routine Backups -System backups are the cheapest safety net you can ever have. Create an environment that encourages frequent system backups of critical systems. Once you identify those systems that are essential, verify the backup method works and test that the backups can be restored. Ransomeware can encrypt your entire network, blocking your access to critical data and systems, but an effective backup system can allow you to completely replace a compromised system without losing any data.
  5. Hire a Professional – While it can be attractive to solve all your technology problems yourself, you should investigate if hiring a professional is a better option. Even a part-time employee, or a consultant solution, can add significant value to a technology project. Finding someone you can call to solve immediate problems, like a crashed system, can allow non-technical employees to focus on the business outside of learning about technology. One data breach could cost you your business much more than you will spend on a qualified professional.

What Security Threat Are You Overlooking?


A recent european IDC survey of more than 400 organizations discovered that many companies fail to address one of the main causes of data exposure, which is an insider threats. The report shows that most security attacks are caused by users unintentionally using outdated credentials to access secure systems. The problem is only 12 percent of companies surveyed considered insider threats as “highly concerning”, with common threats like viruses, phishing, ransomware, etc. listed as bigger threats requiring more attention.

This gap in security thinking can lead organizations to misunderstand users and miss opportunities to detect intentional user breaches.

Businesses need to shift their security focus away from the actions that must happen after a breach, like dealing with the aftermath of ransomware or removing a new virus, and focus on the true source of the problem which is mostly user behavior. Education can go a long way to reduce activity that leads to dangerous behavior, as well as reducing the events that lead to unintentional misuse of user credentials. This should reduce the threats from multiple sources and allow your security team to focus on those users that need additional attention, as well as those users that have attempted the intentional misuse of user credentials.

It is really an effort to stop reacting to attacks caused by uneducated users doing silly things and be proactive on those threats that you can control.


Vulnerability Scanners and HTTP Headers

Network Scans - SeniorDBA

Compliance requirements dictate that companies must perform quarterly internal and external network vulnerability scans. There are a variety of tools that can be used for this purpose, but Nessus is a popular solution.

In this article by Roger McClinton, we get his take on a recent vulnerability listed in this tool.

This week Tenable released a new “plugin” (what they call a vulnerability detection) named “Web Server HTTP Header Information Disclosure”, plugin id 88099. In spite of even the title saying it only an information disclosure vulnerability, they rate this a medium.  In my environment that means we need to address it.  I think its a little crazy for an information disclosure vulnerability to be rated that high. It turns out Tenable has ceded vulnerability severity ratings to the CVSS system.  So because this has a CVSS score of 5 it has to be rated moderate.

Now with SecurityCenter, I’d be able to change the security severity of this detection.  I’m not sure that’s possible in Nessus.  Even so, when scanning servers for other people, you cant just change the results of the scan.  And now the problem, the other party’s security people don’t have the ability to make rational security decisions.  They just want all the detections gone.

You can read the entire article here.

Password Security with SQL Server on Linux and Docker

database security - SeniorDBA

With the recent release of a preview version of SQL Server for Linux and Docker, Microsoft has made it relatively easy to run SQL Server on a non-Windows platform. For example, to install and run SQL Server v.Next on Docker, according to Microsoft’s directions, you would:

  1. Pull the Docker image from Docker Hub
  2. Run the Docker image using the following command
docker run –e 'ACCEPT_EULA=Y' –e 'SA_PASSWORD=<Strong!Passw0rd>' 
-p 1433:1433 -d microsoft/mssql-server-linux

Now the accepted practice to set credentials in the stateless container is to use environment variables. You can see this in the -e parameter ‘SA_PASSWORD=<Strong!Passw0rd>’.

The potential problem with this approach is that the SA credentials will appear in the bash history. Not only this, but the credentials will also show in the output of the ps command (used to list running applications). This effectively exposes the Super User account to any admin with access to the host machine.

Be very careful as you evaluate this SQL Server preview to make sure your are installing SQL Server is securely as possible as you prepare for implementing this product in your production environment in the coming year.

Rethinking Mandatory Password Changes

We are told to change our passwords every 90 days. The primary reason given to uses is that users pick bad passwords and they can only be trusted for less than 90 days before they could be hacked.  Many users will complain that it is difficult to select at least 4 complex passwords a year. If you pair that with the inability to reuse the last 6 passwords (minimum PCI DSS requirement), and the fact that users have more than one account that requires a password, you are looking at the requirement for potentially hundreds (current and recently used) of unique passwords that they may have to remember.

FTC Chief Technologist Lorrie Cranor wrote in March 2016 that it is time to reconsider mandatory password changes:

Unless there is reason to believe a password has been compromised or shared, requiring regular password changes may actually do more harm than good in some cases. (And even if a password has been compromised, changing the password may be ineffective, especially if other steps aren’t taken to correct security problems.)

Their research also showed that once a user password has been hacked, they were able to guess the next password the user would select with relative ease.

The Carleton researchers also point out that an attacker who already knows a user’s password is unlikely to be thwarted by a password change. As the UNC researchers demonstrated, once an attacker knows a password, they are often able to guess the user’s next password fairly easily. In addition, an attacker who has gained access to a user’s account once may be able to install a key logger or other malware that will allow them to continue to access the system, even if the user changes their password.

While there are environments that are less flexible because of compliance requirements, you should look at other solutions to the threat of hacking.

A change in the frequency and type of passwords you require addresses the issue from a users perspective, but doesn’t address the problem of the cyber-mess a user must face when an internet site it hacked and their very complex and long password may still be compromised.

Research suggests frequent mandatory expiration inconveniences and annoys users without as much security benefit as previously thought, and may even cause some users to behave less securely. Encouraging users to make the effort to create a strong password that they will be able to use for a long time may be a better approach for many organizations, especially when combined with slow hash functions, well-chosen salt, limiting login attempts, and password length and complexity requirements. And the best choice – particularly if your enterprise maintains sensitive data – may be to implement multi-factor authentication.

Maybe this holiday season is a good time to rethink your password procedures to see if there is anything you can do to make the situation better for your users.

Installing SQL Server on CentOS Linux

With Microsoft stating their commitment to SQL Server on Linux, system administrators will need to learn how to install, maintain, and use SQL Server. Preview version packages are already available for Red Hat Enterprise Linux 7, CentOS 7, and Ubuntu Server 16.04 64bit.

The only specific system requirement for the preview version is that you must have at least 3.25 GB of RAM.

Installation instructions for CentOS 7:

  1. Insert the following lines into /etc/yum.repos.d/sql-server.repo:

To install the MS SQL Server command-line tools, create /etc/yum.repos.d/msprod.repo with these contents:


2. Then install the packages using yum package manager, as usual:

# yum install -y mssql-server mssql-tools

When the installation is complete, you will be reminded to run the configuration script (/opt/mssql/bin/sqlservr-setup) to accept the license terms, set the password for the SA user, and start the service. Additionally, you can choose to enable it to start automatically on boot.

3. Open port 1433/tcp on your firewall in order to allow external clients to communicate with the database server:

If you’re using firewalld:

# firewall-cmd --add-port=1433/tcp --permanent
# firewall-cmd --reload

Otherwise (using iptables):

# iptables -A INPUT -p tcp --dport 1433 -j ACCEPT
# iptables-save

You can then use your standard SQL Server Management Studio in Windows to connect to the instance.