What Are CIS Benchmarks?

The CIS benchmarks are consensus-driven, best-practice guidelines created by industry experts to enhance the security of IT systems, including SQL Server. Each benchmark outlines specific configuration steps that help harden systems against common vulnerabilities, reduce data breach risk, and support regulatory compliance.

Key CIS Security Benchmarks for SQL Server

1. Control Access and Authentication

Controlling access and using strong authentication methods are foundational security measures.

• Role-Based Access Control (RBAC): Use RBAC to limit user permissions. Only assign necessary permissions to each role, avoiding direct access to administrative privileges.
• Use Windows Authentication: Opt for Windows Authentication over SQL Server Authentication as it integrates with Active Directory, enforcing stronger password policies.
• Disable the “sa” Account: Disable or rename the default “sa” account to reduce unauthorized access attempts.

2. Network and Connection Security

Network security protects SQL Server from unauthorized access.

• Restrict SQL Server Ports: Change the default SQL Server port (1433) and restrict access to trusted IPs to minimize exposure.
• Enable SSL/TLS Encryption: Encrypt data in transit using SSL/TLS, preventing interception between SQL Server and client applications.
• Firewall Configuration: Configure both local and network firewalls to accept connections only from trusted sources.

3. Implement Data Encryption

Encryption safeguards sensitive data in the event of a breach.

• Transparent Data Encryption (TDE): Encrypts data at rest, crucial for sectors handling sensitive data.
• Encrypt Backups: Ensure backups are encrypted to protect data if backup files are compromised.
• Key Management: Use secure encryption keys, ideally using hardware security modules (HSMs), to manage encryption effectively.

4. Logging and Monitoring

Regular logging and monitoring are essential in order to detect unauthorized activity.

• Enable SQL Server Auditing: Enable SQL Server’s auditing feature to track database access and changes in order to monitor potential threats.
• Event Logging: Enable event logging for critical activities, creating a comprehensive log that can be used to analyze security incidents.
• Set Up Alerts for Unusual Activity: Integrate with Security Information and Event Management (SIEM) systems to automate real-time alerts for suspicious activities, such as multiple failed login attempts.

5. Regular Patching and Updates

Keeping SQL Server updated minimizes risk.

• Schedule Regular Updates: Apply cumulative updates and patches as they become available.
• Track SQL Server Vulnerabilities: Stay informed of SQL Server vulnerabilities through Microsoft’s security bulletins and promptly apply necessary updates.

6. Conduct Regular Vulnerability Scans and Audits

Regular scans and audits identify potential security gaps in your SQL Server setup.

• Use Vulnerability Scanning Tools: Use scanning tools to detect weak configurations and insecure practices, like weak passwords.
• Internal Audits: Perform periodic internal audits to ensure that SQL Server settings comply with CIS benchmarks and that best practices remain in place.

Benefits of Aligning SQL Server Security with CIS Benchmarks

Aligning with CIS benchmarks standardizes SQL Server security, reduces breach risk, and helps maintain a compliant and resilient environment. In addition to reinforcing security, these benchmarks simplify management and streamline audit processes, aligning SQL Server security with industry standards like HIPAA, PCI DSS, and SOX.

By implementing CIS benchmarks, organizations not only strengthen SQL Server security but also improve compliance ahead of regulatory audits. You can download the CIS SQL Server benchmarks here for free after providing your email address.

Want to work with The SERO Group?

Ready to implement CIS benchmarks? Schedule a no-obligation discovery call to learn how we can help you create a secure SQL Server environment that meets the highest industry standards.

The post Maximizing SQL Server Security with CIS Benchmarks appeared first on The SERO Group.

In this short video we’ll share six ways to help protect your SQL Servers.

Protect your SQL Server

Spoiler alert! Six steps to protect help protect your SQL Server from attack:

1. If at all possible, don’t expose your SQL Server directly to the internet. Protect them behind a firewall and other multi-layered security measures.
2. Don’t allow weak passwords for sa or any other accounts. Enforce rigorous password complexity requirements.
3. Patch often. Review and apply the latest cumulative updates and applicable hotfixes from Microsoft frequently.
4. Disable the sa account. It’s a well-known login that has unfettered access to the SQL Server instance.
5. Audit failed login attempts and review all newly created logins regularly.
6. Proactively monitor and check your SQL Servers frequently.

These six steps are by no means a comprehensive list of all the security measures that should be taken to protect your SQL Servers. They are just a start, the often overlooked but basic steps to help reduce the surface area of attack on your Microsoft SQL Servers.

By following these steps, along with the others listed here, you can protect your SQL Servers from Malware.

The post Protect Your SQL Server from MrbMiner and Other Malware Attacks appeared first on The SERO Group.

Checking for the “Default” username

You can check for the presence of this login by running the query below. If found, a full network audit is recommended.

--Verify the default account doesn't exist.  No results is a good thing.
SELECT 
	[name],
	[type_desc],
	is_disabled,
	create_date,
	modify_date
FROM sys.server_principals
WHERE [name] = 'Default'

What if you already had a login named “Default”? Determine if the password was recently changed to “@fg125kjnhn987” and if there have been any recent login failures. Review for any recently created logins as well. Are all logins accounted for? Were any created that you were not aware of? If so, review each further to determine what permissions they have and identify what they’re being used for.

--Review recently created logins
SELECT 
	[name],
	[type_desc],
	is_disabled,
	create_date,
	modify_date
FROM sys.server_principals
ORDER BY create_date desc

Review recently modified logins.

--Review recently modified logins
SELECT 
	[name],
	[type_desc],
	is_disabled,
	create_date,
	modify_date
FROM sys.server_principals
ORDER BY modify_date desc

Avoid making your SQL Servers easy targets

By utilizing security best practices, most brute-force attacks can be stopped. Or, at the very least, set off alarm bells and whistles to alert you of suspicious activity. Below is a list of do’s and don’ts we typically recommend. This is not an exhaustive list.

Don’t

1. Don’t expose your SQL Servers to the internet (if at all possible). Use a VPN to access externally.
2. Don’t use weak passwords (for any account).
3. Don’t add your SQL Server service accounts to the local admin group.
4. Don’t grant your SQL Server service accounts more permissions than required.
5. Don’t grant logins more permissions than required.
6. Don’t install additional services which are not required. SQL Server licenses include not only the database engine, but integration services, analysis services, and reporting services as well (at the time of this post). It’s easy enough to go ahead and install these additional services but also increases the attack surface area. Only install what is required.
7. Don’t enable additional options, within SQL Server, if unneeded. For example, xp_cmdshell, Ole Automation Procedures, and ad hoc distributed queries.

Do

1. Patch often. Review latest cumulative update, service pack releases, and hotfixes. Start here.
2. Implement a policy in which an account will become locked out after X number of attempts.
3. Change passwords often.
4. Audit the creation of new logins (and review the audits often 😉).
5. Disable the SA account. This account is well known and has unfettered access.
6. If not required, don’t use SQL Server authentication.
7. Review failed login attempts. Especially those occurring numerous times within a short span of time. This could be an indication of a brute-force attempt.
8. Implement a process to audit using guidelines such as the US government Security Technical Implementation Guides (STIGs) or Center for Internet Security (more on these below).
9. Review the health and performance metrics of your SQL Servers regularly.
10. Proactively monitor your SQL Servers to look for unexpected deviations of resource consumption.

Audit your environment

These types of exploits can typically be avoided. Implementing good security practices can be a painful process (not only from a technical perspective but also from the staff and end user perspective). The following guides provide a large set of information and scripts to get you started with securing your environment.

CIS – Center for Internet Security

CIS Benchmarks are consensus-developed secure configuration guidelines for hardening. There are benchmarks for operating systems, server software, cloud providers, network devices etc. Take a look here for a list of what they have to offer. SQL Server specific benchmarks can be found at https://www.cisecurity.org/benchmark/microsoft_sql_server/. There are some aspects of the site which requires membership but includes additional tools. Well worth the consideration.

National Vulnerability Database

The NCP is the U.S. government repository of publicly available security checklists which provide guidance on setting the security configuration of operating systems and applications. The checklists (STIG) can be downloaded as a zip. To view, download and install the STIG Viewer from https://public.cyber.mil/stigs/srg-stig-tools/ and follow the instructions.

How we can help

Security is constantly evolving. Setting up good policies around platform hardening, password complexity and rotation, and using accounts with the least privilege required is a daunting task for any organization. Especially those without dedicated security or database administrators. I’m hopeful a few of the resources above can get you started on the right path. We’re here to help as well. If you’d like assistance in assessing your SQL Servers, schedule a call with us here.

Thanks for reading!

The post Am I affected by MrbMiner malware? appeared first on The SERO Group.

Guardicore has released a PowerShell script that examines servers to determine if they’ve been infected. We’ve safely run the scripts on SQL Servers in our lab environment and for many of our clients.

If you routinely apply regular updates to your servers, practice the Principle of Least Privilege, regularly change critical passwords, have stringent password complexity requirements, and don’t expose your SQL Servers directly to the internet, the likelihood of a brute force attack succeeding is greatly reduced.

Here are six scripts that can help determine your level of potential exposure.

Who Has sysadmin or serveradmin Privileges?

The Vollgar attack is a brute force attack that attempts to guess the password for SQL Logins with elevated privileges. To be successful it needs logins that can execute sp_configure to change server-level settings. This are implicitly held by the sysadmin and serveradmin fixed server roles.

So, the first step in determining your exposure to Vollgar is to discover the members of the sysadmin and serveradmin roles. The following script will show you the members of each role.

USE master; 
GO

EXEC sp_helpsrvrolemember
	'sysadmin';

EXEC sp_helpsrvrolemember
	'serveradmin';

In my sample database, the following is returned.

Another approach to retrieving the same information in one consolidated result set is to use the following script.

--list of logins that are members of the sysadmin or serveradmin roles
SELECT SP1.[name] AS 'Login',
	SP2.[name] AS 'ServerRole'
FROM sys.server_principals AS SP1
	JOIN sys.server_role_members AS SRM 
		ON SP1.principal_id = SRM.member_principal_id
	JOIN sys.server_principals AS SP2 
		ON SRM.role_principal_id = SP2.principal_id
WHERE SP2.[name] IN ('sysadmin', 'serveradmin')
ORDER BY SP2.[name],
	 SP1.[name];

As expected, this script produces the same results.

Of course, it’s best practice to only grant the minimum rights required by each login, a practice known as least privilege. If these queries return more logins than absolutely necessary, it’s time to review your security practices.

Who has Passwords that Do Not Expire and without Password Complexity Requirements?

Having a complex password and changing it regularly is part of the basic blocking and tackling of security. Passwords like “Password123”, “Qwerty”, and “Puddles!” can be cracked in very short order using tools freely available on the web. And if these passwords never expire, users have no reason to change them regularly, making them even more of a liability.

For Windows Integrated Authentication, password complexity and expiration is handled at the network domain level. For SQL logins, these are enforced inside of SQL Server.

To find active SQL logins (e.g. not disabled) that do not require a basic level of complexity and are set to not expired, run the following script.

--Active SQL Logins where passwords do not expire
--and do not have complexity requirements 
SELECT name, 
	type_desc, 
	create_date, 
	modify_date, 
	default_database_name
FROM sys.sql_logins
WHERE is_expiration_checked = 0
	 AND is_disabled = 0 
	 AND is_policy_checked = 0 ; 

In my sample system, the script produces the following list.

Regularly changing passwords creates a moving target for potential attackers. If you have SQL logins that do not expire and do not have minimum complexity requirements, consider turning these features on for all your logins.

Putting some of the above queries together will give us a list of all active SQL logins that are members of the sysadmin or serveradmin fixed server roles along with whether their logins adhere to password complexity and expiration policies.

--list of SQL logins that are members of the sysadmin or serveradmin roles
SELECT SP1.[name] AS 'Login',
	SP2.[name] AS 'ServerRole',
	CASE l.is_disabled WHEN 1 THEN 'No' ELSE 'Yes' END AS Is_Enabled,
	CASE l.is_expiration_checked WHEN 1 THEN 'Yes' ELSE 'No' End AS Pwd_Expires,
	CASE l.is_policy_checked WHEN 1 THEN 'Yes' ELSE 'No' END AS Pwd_Complexity_Reqs
FROM sys.server_principals AS SP1
	JOIN sys.server_role_members AS SRM
	ON SP1.principal_id = SRM.member_principal_id
	JOIN sys.server_principals AS SP2
	ON SRM.role_principal_id = SP2.principal_id
	JOIN sys.sql_logins AS l
	ON l.principal_id = SRM.member_principal_id
WHERE SP2.[name] IN ('sysadmin', 'serveradmin')
ORDER BY SP2.[name],
	 SP1.[name];

The following results are returned on my test system.

When was a SQL Login Password Changed?

From the prior two queries, we can see that Alice and Donnie are both active members of the sysadmin fixed server role. Donnie’s password doesn’t expire and doesn’t have to meet any password complexity requirements. Of course, this is a big red flag for security. Alice’s login, on the other hand, is set to adhere to complexity and expiration requirements. That’s good.

But how long has it been since Alice actually changed her password? We can use the LOGINPROPERTY() function to help us. Note: that for the function to return meaningful information, both CHECK_POLICY and CHECK_EXPIRATION must be enabled for the login.

--when was a login's password last changed?
SELECT 'Alice' AS username,
	LOGINPROPERTY('Alice', 'PasswordLastSetTime') AS PasswordLastSetTime;

In this case, we can see that Alice last set her password on March 26, 2020.

We can use other properties in the LOGINPROPERTY() function, such as BadPasswordCount and BadPasswordTime. I wouldn’t rely too heavily on the results, though. The BadPasswordCount is reset to 0 as soon as Alice successfully logs in. And, just as importantly, it’s only relevant for those SQL Logins who have CHECK_POLICY and CHECK_EXPIRATION enabled.

--bad password attempts
SELECT name, 
	LOGINPROPERTY(name, 'BadPasswordCount') AS BadPasswordCount,
	LOGINPROPERTY(name, 'BadPasswordTime') AS BadPasswordTime
FROM sys.sql_logins 
WHERE is_expiration_checked = 1
	AND is_disabled = 0 
	AND is_policy_checked = 1; 

The results from my test system are shown below.

How to See Failed Login Attempts

Assuming your SQL Server is configured to log failed login attempts, and of course it should be, you can query the error log files using the sp_readerrorlog procedure to see the failed attempts.

EXEC sp_readerrorlog 0, 1, 'Login failed' ;

The following is returned on my test system.

Better yet, use a monitoring tool to proactively monitor failed login attempts and alert when a minimum threshold is exceeded. For our DBA as a Service clients, we provide SentryOne‘s SQLSentry monitoring tool to help with this and other events that should be monitored.

Parting Thoughts

Many years ago, I set up a test system for a writing project I was involved with. As part of the test, I set the sa password to something like “Cat123Dog!” The password met most requirements of the day – upper and lower case, at least one number and one letter, and a special symbol. “Not bad,” I thought to myself.

Then I downloaded Ophcrack, a free Windows password cracker, and released it on my unsuspecting SQL Server. Expecting the utility to run for hours, if not days, I returned to work.

A few minutes later, I decided to check on it, wanting to make sure it wasn’t hung for some reason. I was stunned. Ophcrack had already found the password! That was at least 10 years ago. I’m sure the tools of the hacker trade have gotten much better since then.

Recently, I’ve read where most breaches are a result of social engineering – someone receives an e-Card from a secret admirer, finds a thumb drive in the parking lot, or clicks an email link. “The days of brute force attacks are over,” they say.

Vollgar has proven them wrong. Basic security measures are still best practice. You owe it to yourself to make sure you’re doing it well. Here are a few links that may help.

• Introduction to SQL Server Security
• Securing SQL Server
• SQL Server Security Checklist

The post Vollgar: 6 Scripts to Help Review Your SQL Servers appeared first on The SERO Group.

Free SQL Server Training Resources

Often these IT Professionals, sometimes called “Accidental DBAs,” do an admirable job, even with little formal SQL Server training. Fortunately, there are a lot of great resources available online for the “Accidental DBA.” Here are a few free SQL Server learning resources worth checking out:

1. Microsoft Resources and Labs

Microsoft has put together quite a few learning opportunities available to the public for free. These are in several different formats so you can pick the one you’re most comfortable with. Here are a few you may want to check out:

1. Microsoft SQL Server 2019 (CTP 3.2) Lab. In this self-paced lab, you’ll learn how to use SQL Server 2019 to solve business challenges.
2. Microsoft AI School. Artificial Intelligence is a hot topic in today’s business environment. In Microsoft AI School, you’ll “find the information, learning materials, and resources you need to start building intelligence into your solutions.”
3. SQL Server Tutorials. More than just Online Documentation, SQL Docs is a great place for detailed information about how to use SQL Server. It includes tutorials that will step you through learning the database technology.
4. EdX. Founded by Harvard and MIT, EdX is a place where education is freely available to everyone online. Microsoft has partnered with EdX to provide free courses online for SQL Server. Here are a few:
   • Querying Data with Transact-SQL.
   • Developing SQL Databases.
   • Analyzing and Visualizing Data with SQL Server Reporting Services.
5. Channel 9. Microsoft produces a lot of video content for SQL Server and other products. They make it available online via Channel 9.

2. YouTube Channels

YouTube can be a great resource for learning just about anything. From changing a tire to playing the ukulele, you can find it on YouTube. It should come as no surprise that there are a lot of great SQL Server training videos available as well. Of course, since just about anyone can create a video, you’ll want to be careful. Not everyone is the expert that they portend to be online. Do your own research. Here are a couple of places to start.

1. SQL Server YouTube Search. A list of SQL Server-related videos.
2. Microsoft SQL Server YouTube Channel. Microsoft SQL Server home on YouTube.

3. SQLSaturdays and Virtual Groups

For many years, I was on the board of Directors for a global user group called PASS. The organization is committed to providing learning opportunities for professionals around the globe and to helping the community to better connect with one another. There are a couple of ways PASS helps with this.

1. SQLSaturdays are a series of free one-day training events in cities around the world. These events, as the name suggests are held on Saturdays and are free to attend. They typically have some of the best and most well-known SQL Server experts around. Look for a SQLSaturday near you and plan to attend. You’ll see some great content and better yet make some incredible connections.
2. Virtual Groups. Through live webinars, PASS Virtual Groups offer top-notch training no matter where you happen to be. Check out a list of upcoming webinars.

Summary

With a new release every 18 to 24 months, keeping up with the latest changes can be a challenge. Hopefully, these free resources will help. We also have an ever growing SQL Script Library available to help get you started with some of the more common tasks.

Want to work with The Sero Group?

Want to learn more about how SERO Group helps organizations take the guesswork out of managing their SQL Servers? It’s easy and there is no obligation. 

Schedule a call with us to get started.

The post Want to Learn SQL Server? Here Are 3 Free Sources appeared first on The SERO Group.

What does that mean?

It means that Microsoft will no longer release any updates for any version of SQL Server 2008. That includes security patches and data integrity fixes. If a hacker finds a zero-day vulnerability and publishes it to the web for all ne’er-do-wells to use, it won’t be fixed. If a new issue is discovered that could lead to data corruption or loss, no fix will be forthcoming. Discover a performance problem? Forget about it. It’s yours alone.

It’s not that Microsoft is heartless or doesn’t care. They do. But they understandably can’t support a version indefinitely. And we’ve known for a long time that this train would leave the station.

Yet many companies are still using SQL Server 2008 and SQL Server 2008 R2 for a lot of different reasons. Too many other projects, fear of a complicated upgrade path, wanting to bundle it with a larger initiative, and simply not knowing where to start are commonly cited reasons for not upgrading. Yet.

What are your options?

Now, the day has come and SQL Server 2008 has officially been mothballed. So, what can you do?

1. The “Do Nothing” Option

If SQL Server 2008 has been working well for you and you don’t see a need to upgrade, it may be that you don’t have to do anything. You could simply continue working as you currently are for a while longer and then sunset the aging applications in due course.

But before you get too excited about this, remember what you’ll forfeit, both now and in the future. Microsoft will not release any hot patches, service patches, cumulative updates, or anything else for the database platform. That’s bad, but that’s not all.

You will also be limited on your operating system upgrades. (Keep in mind that Windows Server 2008 will not be supported after January 14, 2020.)

And if you do decide to upgrade, there will be a substantial amount of technical debt to pay down. The longer you wait, the further entrenched the dated software will become and the more difficult it will be to upgrade or remove.

Although this option may be right for some organizations or instances of SQL Server, it should not be considered for any system that is connected to the internet in any way, even through a VPN. It is risky enough without the possibility of accidentally introducing malicious code.

2. The “One-for-One Upgrade” Option

Sometimes the most straightforward approach is the best approach. If you only have a handful of SQL Servers, you may be able to spin up a new virtual server for each existing database server and migrate to the new servers. This one-for-one approach makes planning and even execution relatively easy. Relatively.

To do it right, however, will take a bit of thought. Before doing anything, you’ll want to run the Data Migration Assistant to check for any potential issues with the upgrade. The DMA will help identify discontinued or deprecated features that your older systems may be using. It’ll also help you discover any potential breaking or behavioral changes that you should be aware before you upgrade.

You’ll also want to make sure you right-size the new environment and configure the new SQL Servers appropriately. Then you can migrate the databases, logins, users, jobs, linked servers, etc. to the new servers. You’ll also want to consider the service accounts used and how they access network resources such as shares used for backups.

Check out our free 5 Common Issues That May Be Putting Your SQL Server At Risk PDF for some common configuration issues we find during our SQL Assessments.

Of course, this option doesn’t consider potential gains that may be realized through server consolidation.

3. The “Consolidation Upgrade” Option

For environments with say ten to forty SQL Servers, it’s worth considering a new SQL Server landscape. The existing SQL Server environment probably grew organically over time without a lot of planning or forethought. New applications were purchased and the easiest thing to do was to spin up a new SQL Server instance for it. Over time, the number of database servers sprawled and now you may have more licenses than you actually need.

The upgrade project is a perfect time to (re)evaluate your landscape.

For this option, you’ll want to:

• Identify the scope and breadth of the project
• Run the Data Migration Assistant to look for possible upgrade issues
• Determine vendor and licensing requirements
• Collect and analyze performance data for each server to determine potential consolidation candidates
• Determine a preliminary consolidation design
• Plan and execute the project

Depending on the scope, you may also want to include a High Availability / Disaster Recovery component to the project.

4. The “Combination” Upgrade

For many environments, especially larger or more complex ones, a combination approach will likely be required, one that incorporates elements from each of the first three options.

Some applications and their associated SQL Servers will be identified as “on their way out” and the first “Do Nothing” approach will be adopted. Use them as-is until you can get rid of them.

Other servers will likely need to be upgraded using the “one-for-one” approach. This will likely apply for larger database servers where resources are a concern. It may also be the case for specific application servers whose vendors insist on sysadmin privileges to the SQL Server. You’ll likely want to separate those application databases to restrict what the vendor has access to.

The majority of the SQL Servers will hopefully be considered candidates for potential consolidation, thus saving some licensing costs and simplifying your environment.

Which option is right for you?

As with most technical questions, the answer is: it depends. There is no clear one-size-fits-all approach for an upgrade project. Consider your timeline and budget, the business requirements and the other projects you have on your plate. Then make the best decision you can.

Not sure where to start? Or don’t have the bandwidth to tackle the upgrade project? We can help. We’ve walked this path before and can help guide you as you take the journey. Give us a call and let’s talk.

The post 4 Options Now That Your SQL Server 2008 Is Out of Support appeared first on The SERO Group.

The scary part is that behind many IIS web sites sits the honeypot that the hackers are after: customer and other proprietary data in a Microsoft SQL Server database. Many websites, such as customer portals, online stores, software-as-a-service sites, and others, contain specific information about individuals that, if exposed, will cost the company dearly.

As my friend and SQL Server expert Steve Jones (@way0utwest) recently tweeted:

“The amount of shareholder value that can be lost due to a data breach is the amount of shareholder value you have.” 

Agreed. A well-targeted attack can bring down a company.

Fortunately, Microsoft SQL Server can be made extremely secure if configured properly. Encryption, Role-based security, Auditing, and other mechanisms allow administrators to define, limit, and monitor access at a very granular level.

The problem is that not all SQL Servers are configured properly. Over 96% of the SQL Server instances we’ve assessed deviate from industry best practices in security, performance, or other configurations. This is troubling.

What can you do? Spend some time with your application developers, with your system and network administrator, and with your DBA team to review the layers of security designed into your systems. Are the Windows Servers patched and up to date? Have the appropriate rules been defined in your firewalls? And, of course, are your SQL Servers configured properly?

Not sure where to start with security for your SQL Servers? Review the following:

• Overview of SQL Server Security
• Securing SQL Server
• MSDN SQL Server Security Blog
• MSSQLTips SQL Server Security Tips

Have questions? Give us a call. Our SQL Server Configuration Assessments maybe a good place for you to start.

The post Are Your SQL Servers Safe? IIS Attacks Increased 782x in One Quarter appeared first on The SERO Group.