One place for hosting & domains


      SQL Server Security Best Practices, Part 2

      This guide is the second in a series of articles that covers SQL Server security best practices.
      Part 1 of this series discussed a SQL Server installation’s physical security, operating system security, and application maintenance. Additionally, the previous guide outlined how to disable unnecessary features, enable encryption, and implement data masking.

      The second part of this series describes how and why you should:

      SQL Server Authentication

      Protection of data stored with SQL Server depends upon the ability to authenticate access to specific sets of data. SQL Server provides two options for database authentication in a Windows or Linux environment:

      You are prompted to select one of these SQL Server authentication modes during SQL Server setup.


      You can change the SQL Server authentication mode even after the initial installation decision has been made.

      Windows or Linux Authentication Mode

      In this mode, an installer logs into SQL Server using their Windows or Linux account. SQL Server validates the account name and password via the Windows or Linux operating system. SQL Server does not prompt for a password and does not perform the validation.

      Windows or Linux authentication uses Active Directory (AD) accounts. As a result, you can have centralized policy control for authentication. Policies can govern password strength and complexity, password expiration, account lockout, and active directory groups in the active directory.

      Windows or Linux-based authentication is the default authentication mode and is much more secure than
      SQL Server Authentication (discussed in the next section). Windows or Linux Authentication uses the Kerberos security protocol to support the above-mentioned security features. A connection made using Windows or Linux Authentication is sometimes called a trusted connection because SQL Server trusts the credentials provided by the underlying Windows or Linux operating system.

      SQL Server and Windows/Linux Authentication Mode (Mixed-Mode)

      When using SQL Server Authentication, logins are created in SQL Server and are not based on Windows or Linux user accounts. Both the username and the password are created
      by SQL Server and are stored within SQL Server. Users connecting using SQL Server Authentication must provide their credentials (username and password) every time that they connect to SQL Server.

      This mode does not use the Windows or Linux Kerberos security protocol, and it is considered to be inferior to
      Windows or Linux Authentication mode.

      System Administrator (SA) Account

      If you are using
      SQL Server (mixed-mode) authentication, SQL Server automatically creates a System Administrator (SA) user login with sysadmin privileges and permissions. To increase the security of your SQL Server, you should perform the following:

      1. Rename the SA login account to a different, more obscure, name.
      2. Disable the account entirely, if you do not plan on using it.
      3. For the SA (or renamed) account, select a complex password, consisting of lower/upper case letters, numbers, and punctuation symbols.
      4. Do not allow applications to use the SA (or equivalently renamed) account in any of the application connection strings.


      Any other user-based (lower-privileged) SQL Server accounts should also use complex, unique passwords.

      High-Privileged Operating System Accounts

      SQL Server uses a Windows or Linux account to run its services. Typically one should not assign high-privileged, built-in accounts (or equivalents) such as Network Service or Local System to the various SQL Server services. This can increase the risk of nefarious database/server activity, should someone be able to log into these types of accounts.

      Only assign the appropriate level of security-required accounts to SQL Server services. If not needed, any high-privileged operating system accounts on the server housing the SQL Server should be disabled as appropriate.

      Restrict SQL Traffic

      Database servers typically have one or more servers connecting to them. Access to these servers must be allowed only to and from designated IP addresses. Doing this can potentially prevent a nefarious user from accessing the server. In certain cases, a user of SQL Server may need to connect directly to the database. Restricting those SQL connections to the specific IP addresses (or at least IP class block or segment) that require it should be implemented.

      These IP restrictions can be managed with different solutions on different platforms:

      SQL Server Patches (Service Packs)

      Microsoft regularly releases SQL Server service packs and/or cumulative packs for fixing known issues, bugs, and security issues. It is highly advisable to apply SQL Server patching on production instances of SQL Server. However, before applying a security patch to production systems, it is advisable to apply these patches in a test environment. This is done to validate the changes in the patch and ensure that your database operates as expected under the patch.


      When dealing with production instances of SQL Server, it is important to regularly backup the server’s databases. A database backup creates a copy of the operational state, architecture, and stored data of a database. Backups help guard against potential database failures. These failures can happen because of corruption, disk array failure, power outages, disasters, and other scenarios.

      Backups can also assist with non-failure scenarios where a rollback of your database to a particular date may be necessary. Full database backups (on a regularly scheduled basis) and incremental backups (on a daily or running time basis) should be performed and maintained.

      Securing your backups is critical, and database professionals sometimes do not consider all of the requirements for securing database backups. This work includes:

      • Restriction of access to backup files. Do not provide all people in your organization the access rights (create, view, modify, and delete) to backup files.

      • Encrypting backup files properly.

      • Storing backups in an off-site facility. Depending on the organization and the critical nature of the database data, backups of a certain age should be preserved and archived.


      Auditing is another key component of SQL Server security. A designated database administrator or database security team should regularly review SQL Server auditing logs for failed logins.

      SQL Server provides a default login audit mechanism for reviewing all of the login accounts. These audit facilities record incoming requests by username and client IP address. Login failures can assist in discovering and eliminating suspicious database activity. The following types of activity can show up in the SQL Server audit logs:

      • Extended Events: Extended Events is a lightweight performance monitoring system that enables users to collect data needed to monitor and troubleshoot problems in SQL Server.

      • SQL Trace: SQL Trace is SQL Server’s built-in utility that monitors and records SQL Server database activity. This utility can display server activity, create filters that focus on the actions of users, applications, or workstations, and can filter at the SQL command level.

      • Change Data Capture: Change Data Capture (CDC) uses a SQL Server agent to record insert, update, and delete activity that applies to a specific table.

      • Triggers: Application-based SQL Server Triggers can be written specifically to populate a user-defined audit table to store changes to existing records in specific tables.

      • SQL Server-Level Audit Specifications: A Server Audit Specification defines which Audit Action Groups can be audited for the entire server (or instance). Some audit action groups consist of server-level actions such as the creation of a table or modification of a server role. These are only applicable to the server itself.

      Hardware and/or software firewall logs (that is, external to SQL Server) should be regularly examined to monitor and detect any nefarious attempts at server penetration.


      In part two of this article series, you reviewed additional methods of enhancing the security of SQL Server databases. These included choosing an
      authentication mode, restricting the
      System Administrator account, assignment of
      security-friendly accounts to SQL Server,
      restricting SQL traffic, application of
      patch updates,
      backup strategies, and use of
      auditing. To review earlier security recommendations, revisit
      Part 1: SQL Server Security Best Practices.

      Source link

      Security Controls for User Accounts

      , by Linode

      Traducciones al Español

      Estamos traduciendo nuestros guías y tutoriales al Español. Es
      posible que usted esté viendo una traducción generada
      automáticamente. Estamos trabajando con traductores profesionales
      para verificar las traducciones de nuestro sitio web. Este proyecto
      es un trabajo en curso.

      Create a Linode account
      to try this guide with a $100 credit.

      This credit will be applied to any valid services used during your first 60 days.

      To protect your Linode user account against unauthorized access, there are several security controls you can implement. This guide covers several of these controls, including 2FA, security questions, and phone verification.

      2FA (Two-Factor Authentication)

      2FA (two-factor authentication) increases the security of your Linode account by requiring two forms of authentication: your password and an expiring token, also called an OTP (one-time passcode) or 2FA code. This follows the security principle of authenticating with something you know (a password) and something you have (the device used to generate the token). This additional layer of security reduces the risk that an unauthorized individual can gain access to your Linode account. Linode highly recommends enabling 2FA. See
      Managing Two-Factor Authentication (2FA) on a User Account
      to learn how to enable 2FA. To assist with account lockouts and recovery, you must first configure three
      security questions
      on your account before enabling 2FA.


      Managing 2FA through Linode is only available if Linode is selected as the Login Method. If you select a third-party authentication provider (such as Google or GitHub), 2FA is managed directly through that provider and not through Linode.

      Security Questions

      You can configure three security questions on your user account. Security questions provide our team with a secure method of verifying your identity as the owner of the user account. They can be used to help you regain access to your account in certain situations, such as when TFA is enabled and you no longer have access to the token or recovery codes. When configuring a security question, answers should not be easily guessed or discoverable through research.

      Configuring Security Questions.

      1. Log in to the
        Cloud Manager
        and navigate to the
        Login & Authentication
        page of your user profile. To do this, click on your username in the top right of the Cloud Manager and select Login & Authentication from the dropdown menu.

      2. Scroll down to Security Questions under the Security Settings section. Here, you can view the security questions available to you or, if you’ve already configured them, see the questions you have selected.

      3. To configure your security questions, click the drop-down field under Question 1 to select the question you wish to use. Then, type the answer in the corresponding box.

      4. Repeat this for Question 2 and Question 3. Once a particular question has been selected, you are not able to select the same one for any other question field.

      5. Once all fields have been configured, click Add Security Questions. You must fill out all 3 questions when adding security questions for the first time.

      6. After a security question has been configured, you can edit one or more questions by clicking the Edit button next to each question you’d like to change, updating the answer field with your new answer, and then clicking the Update Security Questions button.

      Phone Verification

      A verified phone number provides our team with a secure method of verifying access to your Linode user account. It is required for all new accounts created on or after June 27th, 2022, though any existing user can add a verified phone number to increase the security on their account.

      This phone number is only ever used to verify your identity when attempting to authenticate to a user account when contacting Linode Support. An SMS message with a verification code is sent to that phone number. Once received, you can provide that verification code to the Support representative you are in contact with. If you receive a verification SMS without contacting us, do not pass along the verification code to anyone.


      Standard carrier messaging fees apply for each SMS message

      Adding a Verified Phone Number

      1. Log in to the
        Cloud Manager
        and navigate to the
        Login & Authentication
        page of your user profile. To do this, click on your username in the top right of the Cloud Manager and select Login & Authentication from the dropdown menu.

      2. Scroll down to Phone Verification under the Security Settings section. Here, you can view, add, and remove your verified phone number.

      3. To add a phone number, select your country from the dropdown list. This populates the country code portion of the phone number. Then enter the remainder of your phone number.

      4. Click Verify Phone Number to send an SMS verification code.

      5. Once you receive the verification code on your phone, enter it within the Verification Code field. If you do not receive the code within a few minutes, you can click the Resend verification code button.

      6. After successfully entering the verification code, your phone number is verified and has been saved to your user account.

      Multiple User Accounts

      Organizations that require multiple individuals to access the same customer account should create separate user accounts for each individual. Once you’ve created the accounts, you can assign permissions to restrict access to certain Linode services and areas of the Cloud Manager. This is useful for providing all team members access to a single Linode account, allowing a billing department to view invoices and billing details, or granting access to outside developers. For more information, see our guide on
      Accounts and Passwords

      This page was originally published on

      Join the conversation.
      Read other comments or post your own below. Comments must be respectful,
      constructive, and relevant to the topic of the guide. Do not post external
      links or advertisements. Before posting, consider if your comment would be
      better addressed by contacting our
      Support team or asking on
      Community Site.

      Source link

      Application Security Testing Tools

      Application security testing tools help you build applications that are less vulnerable to attacks by automating security testing, and by verifying your applications are secured against known vulnerabilities.

      In this guide, you learn what application security testing is; why you need application security tools; what types of tools exist; and what best practices your organization can use in deploying them.

      What Is Application Security Testing?

      Application Security Testing (AST) is the process of making code more resistant to attack by verifying the absence of known vulnerabilities. Applying security testing practices to all areas of your application’s stack and software development life-cycle can decrease the risk of an incident. Security testing began with manual source code reviews, but that’s no longer feasible in most cases.

      Automated testing with AST tools is a necessity today, for several reasons. These include the complexity of applications, especially web-based and mobile software; the frequent use of third-party components; time-to-market pressures; and the seemingly infinite universe of known attacks.

      The Importance of Security Testing

      You can never completely eliminate risk for your application, but you can use AST tools to greatly reduce that risk. It’s much less difficult and less expensive to detect and fix security flaws early in the development cycle than it is in production.

      Security testing tools also keep you current because they’re regularly updated to check for the latest known vulnerabilities. This is especially important considering that
      2021 saw a record number of zero-day vulnerabilities

      Compared with time consuming code reviews and conventional unit and system test, AST tools provide much more speed and convenience. AST tools also classify and triage test results, helping you quickly identify the most serious vulnerabilities.

      Because they automate testing, software security tools scale well, and ensure repeatable results. AST tools also extend the breadth of security coverage by checking for new classes of vulnerabilities you previously might not have considered. Depending on your industry, there may be cases where you must perform security testing for regulatory and compliance reasons. And perhaps most important of all, AST tools help you think the way attackers do.

      Unlike source code reviews, AST tools work at every stage of an application’s lifecycle. This extends security testing throughout your organization, regardless of whether you’re on a development, devops, or IT management team.

      Types of Application Security Testing

      Static Application Security Testing

      Static application security testing (SAST) tools examine code to detect possible vulnerabilities. SAST tools are a form of white-box testing. In the white-box model, a test tool has access to all aspects of an application’s structure, including its architecture and source code. Armed with this inside knowledge, SAST tools can spot design flaws, identify logic problems, and verify code correctness. These tools optionally may perform negative testing as well, offering illegal values to test input validation and exception handling.

      SAST tools run automated scanning of source code, byte code, or compiled binaries, or some combination of these. The central tenet of all SAST tools is that they examine code at rest. Because SAST tools use a white-box model, they can analyze virtually any aspect of software, including individual functions, classes, and entire applications.

      Most AST tools, including SAST products, compare code against libraries of known vulnerabilities such as the
      Common Vulnerability and Exposures (CVE) list
      . A SAST tool that checks for vulnerabilities in this way might search for coding errors that could lead to privilege escalation, memory leaks, buffer overflows, and other faults.

      Example SAST products include
      AppScan Source
      Checkmarx SAST
      Coverity SAST
      , and the open-source

      Dynamic Application Security Testing

      Dynamic application security testing (DAST) tools examine applications while they’re running. In contrast to SAST tools, DAST takes a “black-box” approach, where the test tool has no visibility into application architecture or coding. Instead, DAST tools must discover vulnerabilities through externally observable means.

      One popular technique employed by DAST tools is the use of fuzzing. This is the practice of deliberately providing software with unexpected or illegal values, often at high rates and/or in high volumes.

      Consider the example of network routing software. A fuzzing tool might bombard routing software with illegal and constantly iterating values for every field in the
      IP header of every packet
      . Fuzzing tests often expose memory leaks or trigger hangs and reboots. They represent an excellent way to detect problems relatively early in development.

      Examples of DAST tools include
      CheckMarx AST
      , and

      As with SAST tools, most DAST products check software integrity against a known set of vulnerabilities and exposures. An interesting, but less common, method is to use a so-called anomaly-based approach, where a test tool monitors application traffic to determine a normal baseline, and then logs behavior outside that baseline.

      Project Ava
      represents an example of the anomaly-based approach.

      While DAST tools work with any type of software, a subset of tools focuses on web application testing. These tools may use some combination of SQL injection (described in detail below), spoofing, cross-site scripting attacks, URL manipulation, password cracking, and other web-specific vulnerabilities.

      Example products include
      , and the
      OWASP Zed Attack Proxy (ZAP)

      SQL Injection Testing

      SQL injection test tools exist as a standalone category because injection attacks are so common, especially against web-based applications. SQL injection attacks work by inserting, or “injecting”, data into SQL queries to compromise a target database.

      For example, a successful SQL injection attack modifies a database by adding, updating, or deleting fields. It may expose personally identifiable information (PII) such as credit-card numbers or medical records. In some cases, SQL injection attacks also send commands to the underlying operating system.

      Because SQL injection attacks are so common, numerous tools exist to automate testing of this class of vulnerabilities. Some examples include
      jSQL Injection
      , and
      . Another open-source tool,
      , automates testing of code-injection vulnerabilities in NoSQL databases such as

      Software Composition Analysis

      Software composition analysis (SCA) tools examine every component and library used by an application, including third-party software. SCA test tools help detect problems in the open-source components or libraries found in the vast majority of networked applications.

      SCA testing uses a hybrid of SAST and DAST approaches. One caveat with SCA tools (and indeed, with any AST tool that uses a set of known vulnerabilities) is that they cannot detect problems they don’t know about. For example, SCA tools cannot detect problems in proprietary libraries developed in-house. Still, SCA tools are invaluable not only to identify vulnerabilities but also for risk management and license compliance needs.

      Vendors of SCA tools include
      Contrast Security
      , and

      Mobile application Security Testing

      As the name suggests, mobile application security testing (MAST) tools look specifically for vulnerabilities in software built for mobile devices. Attackers may target a mobile device’s operating system, or its applications, or both. Some tools focus on apps on mobile devices, while others test back-end services such as cloud platforms and databases.

      Some examples of MAST tools include
      Fortify on Demand
      , and the open-source

      Runtime Application Self-Protection

      Runtime application self-protection (RASP) tools work in production settings by analyzing application traffic and user behavior. RASP uses a hybrid of SAST and DAST approaches, analyzing both source code and live binaries to identify attacks as they happen, and block attacks in real time. For example, a RASP tool may identify an attack that targets a specific API, and then block access to that API. RASP tools also log attempted exploits to external security event and information management (SIEM) systems, allowing for real-time notification.

      Example products include
      Signal Sciences
      , and

      Security Testing Best Practices

      The list below includes five ways that you can make optimal use of AST tools.

      • Shift left. Even with modern software development practices, it’s still common for security testing to begin well after initial coding starts. This is often due to development and test teams working in separate silos. It’s far safer and more efficient to integrate security testing into every development phase – that is, to shift left on project timelines. By shifting left you can reduce bug count, increase code quality, and lessen the chance of discovering critical issues later on during deployment. Security testers should be involved in initial planning, and should be an integral part of any development plan.

      • Don’t trust third-party code. Virtually all networked applications today include third-party components.
        As a famous comic wryly observed
        , modern infrastructure today might well depend on, “a project some random person in Nebraska has been thanklessly maintaining since 2003.” There are many excellent third-party components available, but the onus is on development teams to ensure any outsourced code is free from known vulnerabilities and kept up to date. SCA tools should be an essential part of any AST toolkit.

      • Integrate patch management into CI/CD processes. With the proliferation of zero-day vulnerabilities, it’s no longer sufficient to task IT managers with patch management, the practice of continually updating software to guard against newly discovered attack vectors in software. Certainly patch management is important in production settings, but it’s also critical in earlier stages of the software lifecycle.
        Continuous development and integration (CI/CD)
        teams need to include patching as part of their development processes, and ensure vulnerabilities are mitigated as soon as they’re discovered. This is particularly true when incorporating third-party components such as open-source libraries; those also need to be patched as soon as those projects announce fixes for known vulnerabilities.

      • Think negative thoughts. Especially in early-stage unit testing, it’s all too common to design tests that merely verify a component works as intended. Attackers don’t think this way, and neither should developers. Negative testing – presenting applications with unexpected values – should be part of every test plan.

      • Use all the tools. Information security depends on defense in depth, the concept of employing multiple safeguards to ensure no one component’s failure leads to compromise. In an AST context, this means integrating multiple types of security testing tools into the development process. As aforementioned, there are a wide variety of tools available. Developers, devops teams, and IT managers can greatly improve code security by learning to use these tools, and by implementing them through the application lifecycle.


      To reduce the risk of malicious attacks on your applications, it’s important to use application security testing tools to mitigate any vulnerabilities. This guide covered some of the most important areas of AST, like static application security testing, dynamic application security testing, and SQL injecting testing. These areas help cover security throughout an application’s technology stack and the software development lifecycle. See the
      security basics
      section our documentation library to learn more about security best practices in information technology.

      Source link