Google Introduces Passwordless Secure Sign-In with Passkeys for Google Accounts

May 03, 2023 Ravie Lakshmanan

Almost five months after Google added support for passkeys to its Chrome browser, the tech giant has begun rolling out the passwordless solution across Google Accounts on all platforms.

Passkeys, backed by the FIDO Alliance, are a more secure way to sign in to apps and websites without having to use a traditional password. This, in turn, can be achieved by simply unlocking their computer or mobile device with their biometrics (e.g., fingerprint or facial recognition) or a local PIN.

“And, unlike passwords, passkeys are resistant to online attacks like phishing, making them more secure than things like SMS one-time codes,” Google noted.

Passkeys, once created, are locally stored on the device, and are not shared with any other party. This also obviates the need for setting up two-factor authentication, as it proves that “you have access to your device and are able to unlock it.”

Users also have the choice of creating passkeys for every device they use to login to Google Account. That said, a passkey created on one device will be synced to all the users’ other devices running the same operating system platform (i.e., Android, iOS/macOS, or Windows) and if they are signed in to the same account. Viewed in that light, passkeys are not truly interoperable.

It’s worth pointing out that both Google Password Manager and iCloud Keychain use end-to-end encryption to keep the passkeys private, thereby preventing users from getting locked out should they lose access to their devices or making it easier to upgrade from one device to another.

Passwordless Secure Sign-In with Passkeys

Additionally, users can sign in on a new device or temporarily use a different device by selecting the option to “use a passkey from another device,” which then uses the phone’s screen lock and proximity to approve a one-time sign-in.

“The device then verifies that your phone is in proximity using a small anonymous Bluetooth message and sets up an end-to-end encrypted connection to the phone through the internet,” the company explained.

“The phone uses this connection to deliver your one-time passkey signature, which requires your approval and the biometric or screen lock step on the phone. Neither the passkey itself nor the screen lock information is sent to the new device.”

While this may be the “beginning of the end of the password,” the company said it intends to continue to support existing login methods like passwords and two-factor authentication for the foreseeable future.

Google is also recommending that users do not create passkeys on devices that are shared with others, a move that could effectively undermine all its security protections.

Found this article interesting? Follow us on Twitter  and LinkedIn to read more exclusive content we post.

Source :
https://thehackernews.com/2023/05/google-introduces-passwordless-secure.html

Ubiquiti UniFi Network – UniFi Cloud Adoption (Layer 3)

Updated on 5 mag 2023Print

Layer 3 adoption is the process of adopting a UniFi device to a remote UniFi Network Application. This is only recommended for advanced users, or those adopting devices to the UniFi Cloud Console. 

We highly recommend that users refer to Device Adoption for standard device adoption.

L3 Adoption Methods

For layer 3 adoption, your UniFi Network Application and connected devices must have internet access.

UniFi Network Mobile App

The Cloud Console can leverage your UniFi Network Mobile App (iOS / Android) to provide the easiest L3 adoption experience. 

  1. Refer to our UniFi Device LED Status guide to ensure the device is in a factory-default state.
  2. Connect your mobile device to the same local network as your UniFi device. 
  3. Open your UniFi Network Mobile App and connect to site you want to adopt your device.
  4. Your device should appear for adoption.

DHCP Option 43

This option leverages your DHCP server to inform your UniFi device of the location of your remote Network Application host. Those with a UniFi Gateway can easily accomplish this by entering the IP address of the remote Network Application in Option 43 Application Host Address field located in the Network Settings.

For those using a third-party gateway or DHCP server, we recommend consulting your manufacturer’s documentation to learn more.

DNS

You’ll need to configure your DNS server to resolve ‘unifi’ to your remote UniFi Network Application host.

There are two methods of specifying the Network Application host:

SSH

  1. Make sure your device is in a factory-default state. You can refer to our UniFi Device LED Status guide. 
  2. SSH into the device. You may refer to our guide on how to Login with SSH.
  3. Issue the following command: set-inform http://ip-of-host:8080/inform
  4. The UniFi device will now show up for adoption and can be treated as a standard L2 adoption.

Migrating From Another Network Application

A Layer 3 migration is useful for moving devices from a current Network application to a new Cloud Console. See Backups and Migration for more information.

Source :
https://help.ui.com/hc/en-us/articles/204909754

Ubiquiti UniFi Recovery Mode

Updated on 5 mag 2023Print

Recovery Mode is a last-resort solution to recover an unresponsive UniFi device, often resulting from power loss occurring at the same time as an update. Only use Recovery Mode if you are unable to perform a standard factory reset.

Note: UniFi Power Backup can prevent unexpected power losses from occurring.

The following UniFi devices support Recovery Mode:

  • Dream Machine, Dream Machine Pro & Dream Wall
  • Access Points (all models)
  • Cloud KeyCloud Key Gen2+
  • Cameras
  • USW Flex Mini

Before Considering Recovery Mode

If you are considering Recovery Mode, first check two key points:

  1. Reboot your UniFi device. If this resolves your symptoms, no further actions are required.
  2. Factory reset your UniFi device. If you have cloud backups, you can easily restore your settings after factory resetting. If a factory reset works, no further actions are required.

Performing a Device Recovery

Dream Machine, Dream Machine Pro & Dream Wall

  1. Download the most recent firmware for your device, found here.
  2. Completely power-off the UniFi device and unplug it from its power source.
  3. Press and hold the Reset button and then reconnect it to the power source.
  4. Continue holding the Reset button for 5 seconds, or until the display (in supported models) indicates Recovery Mode.
  5. Connect an Ethernet cable from your computer to the first LAN port (Port 1). This is usually the port nearest to the top left corner.
    • Note: Connect to the Dream Wall via Port 18, not Port 1.
  6. Configure a static IP address on your computer in the 192.168.1.0/24 range (for example, 192.168.1.11).

Windows Client

  1. Navigate to the Windows 10 Network connections
    • Settings > Network & Internet > Status > Change Adapter Option
  2. Modify the IPv4 settings of the Ethernet adapter
    • Ethernet Adapter > Properties > Internet Protocol Version 4 (TCP/IPv4) > Propertie
  3. Select the option to manually enter an IP address and add the following information:
    • IP address: 192.168.1.11
    • Subnet mask: 255.255.255.0
    • Default gateway: <blank>
    • DNS servers: <blank>

macOS Client

  1. Navigate to the mac OS Network connections.
    • System Preferences > Networks > Ethernet Adapter
  2. Select to manually enter an IP address and add the following information:
    • IP Address: 192.168.1.11
    • Subnet Mask: 255.255.255.0
    • Router: <blank>
    • DNS server: <blank>
  1. In a web browser, navigate to http://192.168.1.30 to access the Recovery Mode UI.
    • Note: The Recovery Mode UI is accessible via HTTP only (not HTTPS). Your browser may try to redirect your session to HTTPS. Use a different browser if necessary.
  2. Select Firmware Update > Choose and browse your computer for the previously downloaded firmware (.bin) image file.
  3. Wait for the upgrade process to complete and reboot the device afterwards.

Access Points

  1. Download the most recent firmware for your device, found here.
  2. Connect your AP and computer to the same network or VLAN, either through a PoE switch or by connecting the computer directly to the network (data) port on the PoE adapter.
  3. Press and hold the Reset button, and connect your computer to the available ethernet port of the AP.
  4. Continue holding the Reset button until the LED flashes white, blue, off as indicated in our LED Status Guide. This indicates your device is ready for TFTP Recovery and you can release the button.
  5. Set a static IP address on your computer to communicate with the AP, which has a default IP address of 192.168.1.20. The following is an example configuration:
    • Static IP: 192.168.1.25
      Subnet: 255.255.255.0
      Gateway: 192.168.1.20
  6. Use TFTP to move the firmware from your computer to your AP. There are various programs and methods for accomplishing this. Here are two methods for your reference.
    • Windows
      1. Use the built-in TFTP command line tool, or a separate program such as Tftpd64 or pumpKIN.
      2. Select the downloaded firmware image and transfer it to the AP.
    • macOS and Linux
      1. Open Terminal
      2. Enter TFTP mode by entering the command:tftp
      3. Once in TFTP, paste the following commands and hit enter.connect 192.168.1.20
        binary
        rexmt 1
        timeout 60
        put /path/to/firmware_name.bin
  7. The file transfer will begin. The firmware will upgrade and the device will automatically reboot once it has finished. Do not reboot it yourself.

Cloud Key

Cloud Key Gen2, Gen2 Plus

  1. Download the most recent firmware for your device, found here.
  2. Power off the system.
  3. Press and hold the Reset button and then connect it to the power source.
  4. Continue holding the Reset button for 10 seconds, until the LED flashes blue and white. The LCD screen on the front panel will also read “RECOVERY MODE.”
  5. Open your browser and type the IP address for the Cloud Key, visible on the device’s screen.
    • Note: The IP address comes from your DHCP server. If it has not been assigned an IP address, you can try the fallback: 192.168.1.30.
  6. Run the “Check Filesystem” to try searching for and repairing any problems with your storage disk that may cause system issues.
  7. Restore the firmware you downloaded in step (1). Note that this will also factory reset your device.
  8. The LED will flash white while upgrading and turn into a steady white when it is complete.
  9. If your device fails again, this is a sign that you should replace your storage disk.

Cloud Key (Gen1)

  1. Download the most recent firmware for your device, found here.
  2. Power off the system.
  3. Press and hold the Reset button and then connect it to the power source.
  4. Continue holding the Reset button for 10 seconds, until the LED flashes blue and white.
  5. Open your browser and type the IP address for the Cloud Key.
    1. Note: The IP address comes from your DHCP server. If it has not been assigned an IP address, you can try the fallback: 192.168.1.30.
    2. If your Cloud Key does have an IP address assigned by the DHCP server, the fallback IP will not work.
    3. User Tip: If you don’t know your Cloud Key’s IP address, you can use thearp -a SSH command, or software such as nmap to find the IP address.
  6. You will be taken to the Recovery Mode screen. From here you can reset, reboot, power off and most importantly upload an updated firmware bin file.
  7. Upload the firmware you downloaded in step (1).
  8. Once it is uploaded, reboot the Cloud Key to complete the firmware upgrade.
  9. The LED will flash white while upgrading and turn into a steady white when it is complete.

Cameras

  1. Unplug the PoE cable from the camera.
  2. Press and hold the Reset button, then reconnect the camera to its PoE cable.
  3. Continue holding the Reset button for at least 10 seconds, or until you see the LED flash 3 times rapidly.
  4. Release the Reset button.
  5. The device will automatically reboot to an older firmware. 
  6. To update to more recent firmware:
    1. Find your specific camera model at our Downloads page using the left hand menu.
    2. Copy the .bin file link of the firmware.
    3. Use that link to upload it via the webUI of the camera, in System Settings.
      1. Alternatively, adopt the camera to your NVR to perform an upgrade via the NVR-hosted UniFi Video user interface.

USW Flex Mini

  1. Prepare a web server (see below*).
  2. Set the server/computer’s IP to a static 192.168.1.99.
    1. The method to set a static IP on a computer varies from platform to platform. Find instructions in your product’s documentation (Windows, macOS or Ubuntu/Linux).
  3. Download the most recent firmware for your device, found here.
  4. Rename the binary to fwupdate.bin and place it in the directory that was created earlier (webserver).
  5. Power off the switch by unplugging it from its power source.
  6. Press and hold the Reset button and then connect it to the power source.
  7. Continue holding the Reset button for 10 seconds, until the LED flashes blue, white, off.
  8. The USW-Flex-Mini should be updated.

* The first step in the recovery process is to prepare a web server. See below for a walkthrough on your operating system: Windows, macOS and Ubuntu/Debian. 

Prepare a Web Server on Windows

  1. Download Python for Windows (Executable Installer) here.
  2. Open the downloaded file and make sure you select Add Python x.x to PATH during installation.
  3. After the Python installation open Command Prompt as Administrator and confirm that Python is installed correctly with the command below:
    python -V
  4. Create a directory for the web server by running the commands below:
    mkdir c:\webserver
    cd c:\webserver
  5. 5. Start the Python web server on port 80. Note that the version of Python can be found with the command from step 3:
    1. Python 3.x:
      python -m http.server 80
    2. Python 2.x:
      python -m SimpleHTTPServer 80

Prepare a Web Server on macOS

  1. Download Python for macOS here.
  2. After the Python installation open Terminal and confirm that Python is installed correctly with the command below:
    python -V
  3. Create a directory for the web server by running the commands below:
    cd ~
    mkdir webserver
    cd webserver
  4. Start the Python web server on port 80. Note that the version of Python can be found with the command from step 2:
    1. Python 3.x:
      python -m http.server 80
    2. Python 2.x:
      python -m SimpleHTTPServer 80

Prepare a Web Server on Ubuntu/Debian

  1. Install Python on your machine with the commands below:
    sudo apt-get update && sudo apt-get install python3
  2. After the Python installation open a terminal and confirm that Python is installed correctly with the command below:
    python_version=$(dpkg -l | grep “^ii” | awk ‘/python/{print$2}’ | grep “^python[0-9].[0-9]$” | head -n1)
    sudo “${python_version}” -V
  3. Create a directory for the web server by running the commands below:
    cd ~
    mkdir webserver
    cd webserver
  4. Start the Python web server on port 80. Note that the version of Python can be found with the command from step 2:
    1. Python 3.x:
      sudo “${python_version}” -m http.server 80
    2. Python 2.x:
      sudo “${python_version}” -m SimpleHTTPServer 80

Source :
https://help.ui.com/hc/en-us/articles/360043360253-UniFi-Recovery-Mode

Ubiquiti UniFi – Tuning the Network Application for a High Number of UniFi Devices

Updated on 4 mag 2023Print

This article only applies to advanced users running UniFi on their own Windows/macOS/Linux machine, to help diagnose and optimize self-hosted UniFi Network Servers running under a high load. We generally recommend using a UniFi OS Host for the best experience. Visit UI.com to learn more.

Notes & Requirements:

  • Ensure you are running the latest version of UniFi Network, found here.
  • This article describes advanced configuration options and should only be attempted by advanced users.
  • Create a backup prior to following the instructions in this article. See UniFi – Backups and Migration for more information.

Caution must be taken when self-hosting a UniFi Network Server if there are hundreds of UniFi devices connected across multiple sites. This increased system load may lead to performance degradation if certain things are not optimized.

Symptom: High CPU Usage

One of the most important metrics to monitor is the CPU usage of the UniFi Host. High CPU usage is the first indication that there is an issue. Unfortunately there is no easy solve for this, and merely increasing the CPU is not always the answer.

Allocating Additional Memory

Before increasing the RAM allocation on your machine, first try increasing the `XMX` and `XMS` options. By default, the UniFi Network application has these set to 1GB. The following lines set the xmx and xms to values to 2GB (2048MB):

unifi.xmx=2048
unifi.xms=2048

The changes above would increase the memory that the UniFi Network application is allowed to consume from 1 to 2GB. Before moving to a machine with more CPU resources, it is recommended to max out the available memory on that machine with the above settings to see if CPU usage decreases.

If 2GB is not sufficient, administrators may want to raise the limit to 4, 8, 16, or even 32GB depending on the scale. In this case it would simply be increasing the value above in increments of 1024, i.e. 4 GB= 4096.

Note: The jstat -gcutil Java command can be used to check whether the memory allocation is sufficient on your machine. See the Oracle documentation for more information.

Increase Mongo WiredTiger Engine Cache

If you already increased the UniFi Network application memory settings to at least 4GB (xmx), you may need to also change the default Mongo WiredTiger engine cache. By default the UniFi Network Application uses:

db.mongo.wt.cache_size=256

On UniFi Network version 6.5.13 and above you can change this setting or let Mongo pick the default value by using:

db.mongo.wt.cache_size_default=true

For more information please refer to Mongo documentation.

Enabling High Performance Java Garbage Collector

If increasing memory does not solve the problem, administrators may consider also adding this line to the system.properties file:

unifi.G1GC.enabled=true

This enables a new Java Garbage Collector that can help optimize performance. However, if after these changes high CPU usage does continue after memory increase, a larger machine with more CPU cores and more memory to handle the workload may be necessary.

Changing Mongo Version/Engine

In persistent cases, administrators may consider updating MongoDB version to 3.2+ with WiredTiger as storage engine, as a means of better scaling their UniFi Network deployment. See the following links for instructions:

Symptom: Heartbeat Missed or Slow to Provision

All devices work by communicating to UniFi Network. These regular inform messages are referred to as “heartbeats”. By default, the application can handle 200 simultaneous device connections so heartbeats shouldn’t be missed unless thousands of devices are being managed. The number of simultaneous inform messages that can be processed can be set in the system.properties file by adding the following lines and adjusting the values to best suit your needs. It does not matter where these lines are added in the file.

inform.num_thread=200
inform.max_keep_alive_requests=100

The default value is 200 and the max_keep_alive_requests value should always be lower than than num_thread. Try adjusting up from there. An increase in device stability should be seen, and by pushing the configuration out to other devices, become even more stable. 

Database Connection Tuning

When running a large UniFi installation, it may be desired to run an external Mongo cluster to be able to scale the database independently from the UniFi Network application. Discussion on that can be found here on our Community Beta forum. If high CPU usage is seen on the Mongo process, it can indicate the need of a bigger box or the need to separate the mongodb process as mentioned above. Once that is done, the following can be tuned to see if it results in better application performance: 

db.mongo.connections_per_host=100
db.mongo.threads_multiplier=5

This results in 500 threads that can be waiting for a Mongo connection. So keep in mind that more threads can mean higher CPU usage because the CPU has to context-switch between threads. It may allow for higher DB throughput, but only if the Mongo process is able to consume more CPU to serve requests faster. 

Source :
https://help.ui.com/hc/en-us/articles/115005159588-UniFi-Tuning-the-Network-Application-for-a-High-Number-of-UniFi-Devices

Ubiquiti UniFi – Repairing Database Issues on the UniFi Network Application

Updated on 1 mag 2023Print

Use this article to repair the database of malfunctioning UniFi Network applications. Please note this only applies to users self-hosting the UniFi Network Server on their own Windows/macOS/Linux machine, or those hosting UniFi Network on a legacy Cloud Key.

We generally recommend using a UniFi OS Host for the best experience. Visit UI.com to learn more. 

Symptoms

  • Statistics are only recorded for a few days and then are cut off or are only intermittently available.
  • Backups including statistics data cannot be generated.
  • Settings-only backups cannot complete, or are created but are unable to be restored due to corruption.
  • An error 400 is generated when trying to open UniFi Network.
  • The UniFi Network application service will not start due to database errors.

32-bit MongoDB Limitations

32-bit MongoDB collections are limited to a total size of 2GB. While running the MMAPv1 storage engine this can cause issues when trying to shrink the aggregate collection sizes. When running a compact command on the MongoDB, the database is rewritten and defragmented without error correction. This process does not return useable disk space to the UniFi Host when the storage engine is MMAPv1.

Getting back that valuable disk space on a 32-bit MongoDB instance will require a repair of the database. This repair may be needed for those who are suspecting invalid entries, corruption, or collection scaling issues. To be able to run a database repair, the Cloud Key will have to have enough free disk space equal to the size of the current data set plus 2 gigabytes. If the dataset has already grown too large to proceed with the db.repairDatabase() command there are instructions below to work around that.

Note: The Legacy Cloud Key (UC CK) utilizes the following:

  • 32-Bit architecture
  • MMAPv1
  • MongoDB Version 2.4.10

Repairing a Cloud Key Database

  1. Establish an SSH connection with the Cloud Key.
  2. Download the mongo pruning script. As written, the script will only keep entries from the past 7 days. It will not remove entries that are required for UniFi administration. Do so by running the following command:
    cd /tmp/ wget https://help.ui.com/hc/en-us/article_attachments/360008640574/CK_repair.js
  3. Stop the UniFi service:
    service unifi stop
  4. The UniFi service will shut down the mongo process. Make sure that the UniFi service has been completely shut down. Repair the database to compact the data entries and free unused disk space field that is included in the query criteria.
    mongod –dbpath /usr/lib/unifi/data/db –smallfiles –logpath /usr/lib/unifi/logs/server.log –repair
    1. NOTE: Steps 5-8 are optional if you need to prune back the database to conserve disk space.
  5. Restart mongo using:
    mongod –dbpath /usr/lib/unifi/data/db –smallfiles –logpath /usr/lib/unifi/logs/server.log –journal –fork
    1. NOTE: Journaling may not be have been enabled in your mongo database. If so, then remove the –journal option in the above command.
  6. Execute the script to prune the stat collections that are causing the problem:
    mongo < /tmp/CK_repair.js
  7. Shut down the mongo server with this command:
    mongod –dbpath /usr/lib/unifi/data/db –smallfiles –logpath /usr/lib/unifi/logs/server.log –shutdown
    1. Note: The last command in the CK_repair.js script is “db.repairDatabase()”. It may result in an error if the stats collections have already grown too large to be repaired while the mongo server is running. If you see such an error running the script then you will need to repair the database from the command line once again by running the command in step 3.
  8. Finally, restart the UniFi service:
    service unifi start

The Cloud Key should now be able to run the Network application. If you still have database issues, please upgrade to the latest Cloud Key Gen2 Plus which does not experience this problem.

Repairing a Debian-based Linux Database

  1. Stop the UniFi service
    service unifi stop
  2. In some cases, where the journal is corrupted, it will be helpful to run the following command before repairing the database, to move it to another location:
    mv -vi /usr/lib/unifi/data/db/journal /usr/lib/unifi/data/db/journal-$(date -I)
  3. Repair the database with this command:
    mongod –dbpath /usr/lib/unifi/data/db –smallfiles –logpath /usr/lib/unifi/logs/server.log –repair
  4. Finally, restart the UniFi service:
    service unifi start
    1. Note: If this process was performed as root the file ownership may have changed. This can be changed with:
      chown -R unifi:unifi /usr/lib/unifi/data/db/
      chown -R unifi:unifi /usr/lib/unifi/logs/server.log

If you still have suspected database issues please migrate to a Cloud Key Gen2 Plus or Dream Machine Pro. These UniFi OS Hosts do not experience this type of database corruption.

Repairing a macOS Database

  1. Create a temporary working directory. For repair purposes, we will call this directory /repair. In terminal:
    mkdir ~/repair
  2. Visit the MongoDB official download website, and download the .tgz release that corresponds to your server’s CPU architecture.
    1. You can also download 2.4.14 here directly: 2.4.14.tgz
  3. Move the downloaded package to your working directory, and extract it by double-clicking it or using the application of your choice.
  4. Locate the bin/mongo binary file, and copy it to your working directory.  At this point, the downloaded .tgz package and any extra extracted files can be deleted as we only need the mongo binary.
  5. Open Terminal and move to your working directory:
    cd ~/repair
  6. Close or stop UniFi.
  7. Repair the database with this command:
    mongod –dbpath ~/Library/Application\ Support/UniFi/data/db –smallfiles –logpath ~/Library/Application\ Support/UniFi/logs/server.log –repair
  8. Open the UniFi application from Finder:
    open -n /Applications/UniFi.app

If you still have suspected database issues please migrate to a Cloud Key Gen2 Plus or Dream Machine Pro. These UniFi OS Hosts do not experience this type of database corruption.

Repairing a Windows Database

  1. Visit the MongoDB official download website, and download the .zip release that corresponds to your CPU architecture.
    1. Note: The recommended MongoDB version is 3.4.x. You can download 3.4.23 directly here: 3.4.23.zip.
  2. Extract \bin\mongod.exe to a working directory of your choice.  In this example, we will use C:\repair\ You may ignore all other files included in the .zip.
  3. Close or stop UniFi.
  4. Open the command prompt by pressing WINDOWS + R.  In the popup, type cmd, and press ENTER.
  5. Enter Working Directory:
    cd C:\repair\
  6. Repair the database with this command:
    mongod.exe –dbpath “%userprofile%\Ubiquiti UniFi\data\db” –smallfiles –logpath “%programfiles%\Ubiquiti UniFi\logs\server.log” –repair
  7. Open the UniFi application.

If you still have suspected database issues please migrate to a Cloud Key Gen2 Plus or Dream Machine Pro. These UniFi OS Hosts do not experience this type of database corruption.

How to Migrate from MMAPv1 to WiredTiger

Attention: This section does not apply to 32-bit architecture hosts including the UC-CK G1.

After UniFi Network is functional again, a user may wish to migrate it to the WiredTiger storage engine.

To verify how much space is used, run the following command:

du -shc /usr/lib/unifi/data/db/ace* /usr/lib/unifi/data/db/journal/* /usr/lib/unifi/data/db/local* | grep total

To verify which MongoDB version is being used, run the following:

mongod --version | grep "db version"

To verify what storage engine version is being used, run the following two commands:

mongo localhost:27117
db.serverStatus().storageEngine.name

How to Migrate to WiredTiger

  1. Create a backup under Settings > Maintenance > Backup with the desired retention settings.
  2. Uninstall UniFi from Windows or macOS. Purge UniFi from Debian-based Linux with the command:
    sudo dpkg -P unifi
  3. Reinstall UniFi on Windows or macOS. Reinstall UniFi on Debian-based Linux with the commands:
    cd /tmp/
    wget <https link to download>
    sudo dpkg -i unifi_sysvinit_all.deb
  4. In the UniFi Setup Wizard restore the backup from step 1.

Source :
https://help.ui.com/hc/en-us/articles/360006634094-UniFi-Repairing-Database-Issues-on-the-UniFi-Network-Application

Ubiquiti Self-Hosting a UniFi Network Server

Updated on 5 mag 2023Print

Self-hosting a UniFi Network Server should only be done by experienced network administrators. For the best and most streamlined experience, we recommend running UniFi Network on a UniFi OS Console or other UniFi OS Host, such as a Cloud Key. This will eliminate compatibility risks associated with third-party software and hardware.* Other benefits of UniFi OS Hosts include:

  • Optimized hosting and management performance
  • Automatic scheduling of backups and updates
  • Seamless email and mobile push notifications for important system activity

*UniFi also offers the Cloud Key Enterprise (on-premise) and a native Cloud Hosting subscription for scaleable deployments managing hundreds of UniFi APs.

If you choose to continue, see below for instructions to install the UniFi Network Application on your device.

Instructions

Windows

Linux

macOS

  1. Download the latest version of the UniFi Network application (UniFi-installer.exe) from the Download page.
    1. The latest versions of the UniFi Network Application (7.3) require Java 11.
    2. Previous versions (7.2) use Java 8.
    3. Install only the x64 Java release and only one version of Java.
  2. You will be prompted to install Java 11. Select the following options and download the x64 .msi file for Windows:
    1. Package Type: JRE
    2. Version: 11
  3. Install Java, and set the Set JAVA_HOME variable to Will be installed on local hard drive.
image.png
  1. After installing Java, continue the UniFi Network application installation and start it.
  2. Ensure that any anti-virus/spyware programs and the Windows firewall are not blocking the application.
  3. Open a browser, navigate to https://localhost:8443 and proceed when seeing the security warning.
  4. Proceed with the setup wizard.
  5. Adopt your first UniFi device.

Frequently Asked Questions

1. Does the UniFi Network application have to run at all times?

If the UniFi Network application is turned off, adopted UniFi devices (access points, switches) will keep functioning. 

However, it is highly recommended to keep the UniFi Network application running at at all times. This enables you gather accurate statistics and make configuration changes whenever needed. 

If you are not able to keep the Self-Hosting Network Server running continuously, then we recommend to upgrade to a UniFi OS Console, which is optimized to run UniFi Network and other applications.

2. Can I manage UniFi Devices that are adopted by another UniFi Network application?

No. The UniFi Network application installed on Windows/macOS/Linux is not a viewer for other UniFi Network applications (running on UniFi OS Consoles or other hosts).

3. The UniFi Network application is running slow.

Verify if the Self-Hosted Network Server is capable of running the UniFi Network application. The more UniFi and client devices that are connected, the more resources that will be needed.

Please be aware that self-hosting the UniFi Network application is an advanced setup for those familiar with network administration. If you are experiencing poor performance, we recommend upgrading to a UniFi OS Console, which is optimized to run UniFi Network and other applications.

4. The UniFi Network application is not able to start.

Verify if the Self-Hosted Network Server is capable of running the UniFi Network application and that the correct version of Java is installed. 

If you continue to experience issues, try installing the application on a different host machine.

Please be aware that self-hosting the UniFi Network application is an advanced setup for those familiar with network administration. If you are unable to get the UniFi Network application running on your host machine, we recommend upgrading to a UniFi OS Console, which is optimized to run UniFi Network and other applications. 

5. The UniFi Network application starts up, but I do not see any nearby UniFi devices.

Make sure that the firewall on the host machine is allowing the ports needed by UniFi and that the UniFi Network application is not blocked by any anti-virus/spyware programs.

Also make sure that the UniFi devices and the application are on the same network. If not, then remote adoption is required.

6. I get a “Your connection is not private” warning when accessing via my browser.

This can be safely ignored. Proceed to the next page.

7. What are the UniFi Network application system requirements?

At a bare minimum, we recommend the following system requirements (make sure to read the Release Notes for more details about a particular version):

  • Operating system:
    • Linux: Ubuntu Desktop / Server 22.04; Debian 11 “Bullseye”
    • Windows: Windows 10; Windows Server 2016
    • macOS: Mavericks 10.9, 10.10 Yosemite, 10.11 El Capitan, 10.12 Sierra, 10.13 High Sierra, 10.14 Mojave, 10.15 Catalina.
  • CPU: x86-64 Processor (Intel / AMD x64 Processors)
  • RAM: 2GB
  • Network: 100Mbps Wired Ethernet
  • HDD: Minimum 10GB free (20GB or more preferred)
  • Java: Java Runtime Environment (JRE) 11
  • Web Browser: Google Chrome
  • MongoDB: version 3.2 or later. Mongo is offered bundled: default is 2.4.14 (for macOS and Windows only).

Note: You will need to continually increase your system specs as you begin to adopt and manage more devices.

Source :
https://help.ui.com/hc/en-us/articles/360012282453-Self-Hosting-a-UniFi-Network-Server

NIST Password Guidelines

Joe Dibley

Published: November 14, 2022

Updated: March 17, 2023

What are NIST Password Guidelines?

Since 2014, the National Institute of Standards and Technology (NIST), a U.S. federal agency, has issued  guidelines for managing digital identities via Special Publication 800-63B. The latest revision (rev. 3) was released in 2017, and has been updated as recently as 2019. Revision 4 was made available for comment and review; however, revision 3 is still the standard as of the time of this blog post.

Section 5.1.1 – Memorized Secrets provides recommendations for requirements around how users may create new passwords or make password changes, including guidelines around issues such as password strength. Special Publication 800-63B also covers verifiers (software, websites, network directory services, etc.) that validate and handle passwords during authentication and other processes.

Handpicked related content:

Not all organizations must adhere to NIST guidelines. However, many follow NIST password policy recommendations even if it’s not required because they provide a good foundation for sound digital identity management. Indeed, strong password security helps companies block many cybersecurity attacks, including  hackers, brute force attacks like credential stuffing and dictionary attacks. In addition, mitigating identity-related security risks helps organizations ensure compliance with a wide range of regulations, such as HIPAA, FISMA and SOX.

Quick List of NIST Password Guidelines

This blog explain many NIST password guidelines in detail, but here’s a quick list:

  • User-generated passwords should be at least 8 characters in length.
  • Machine-generated passwords should be at least 6 characters in length.
  • Users should be able to create passwords at least 64 characters in length.
  • All ASCII/Unicode characters should be allowed, including emojis and spaces.
  • Stored passwords should be hashed and salted, and never truncated.
  • Prospective passwords should be compared against password breach databases and rejected if there’s a match.
  • Passwords should not expire.
  • Users should be prevented from using sequential characters (e.g., “1234”) or repeated characters (e.g., “aaaa”).
  • Two-factor authentication (2FA) should not use SMS for codes.
  • Knowledge-based authentication (KBA), such as “What was the name of your first pet?”, should not be used.
  • Users should be allowed 10 failed password attempts before being locked out of a system or service.
  • Passwords should not have hints.
  • Complexity requirements — like requiring special characters, numbers or uppercase letters — should not be used.
  • Context-specific words, such as the name of the service or the individual’s username, should not be permitted.

You probably notice that some of these recommendations represent a departure from previous assumptions and standards. For example, NIST has removed complexity requirements like special characters in passwords; this change was made in part because users find ways to circumvent stringent complexity requirements. Instead of struggling to remember complex passwords and risking getting locked out, they may write their passwords down and leave them near physical computers or servers. Or they simply recycle old passwords based on dictionary words by making minimal changes during password creation, such as incrementing a number at the end.

NIST Guidelines

Now let’s explore the NIST guidelines in more detail.

Password length & processing

Length has long been considered a crucial factor for password security. NIST now recommends a password policy that requires all user-created passwords to be at least 8 characters in length, and all machine-generated passwords to be at least 6 characters in length. Additionally, it’s recommended to allow passwords to be at least 64 characters as a maximum length.

Verifiers should no longer truncate any passwords during processing. Passwords should be hashed and salted, with the full password hash stored.

Also the recommended NIST account lockout policy is to allow users at least 10 attempts at entering their password before being locked out.

Accepted characters

All ASCII characters, including the space character, should be supported in passwords. NIST specifies that Unicode characters, such as emojis, should be accepted as well.

Users should be prevented from using sequential characters (e.g., “1234”), repeated characters (e.g., “aaaa”) and simple dictionary words.

Commonly used & breached passwords

Passwords that are known to be commonly used or compromised should not be permitted. For example, you should disallow passwords in lists from breaches (such as the Have I Been Pwned? database, which contains 570+ million passwords from breaches), previously used passwords, well-known commonly used passwords, and context-specific passwords (e.g., the name of the service).

When a user attempts to use a password that fails this check, a message should be displayed asking them for a different password and providing an explanation for why their previous entry was rejected.

Reduced complexity & password expiration

As explained earlier in the blog, previous password complexity requirements have led to less secure human behavior, instead of the intended effect of tightening security. With that in mind, NIST recommends reduced complexity requirements, which includes removing requirements for special characters, numbers, uppercase characters, etc.

A related recommendation for reducing insecure human behavior is to eliminate password expiration.

No more hints or knowledge-based authentication (KBA)

Although password hints were intended to help users to create more complex passwords, users often choose hints that practically give away their passwords. Accordingly, NIST recommends not allowing password hints.

NIST also recommends not using knowledge-based authentication (KBA), such as questions like “What was the name of your first pet?”

Password managers & two-factor authentication (2FA)

To account for the growing popularity of password managers, users should be able to paste passwords.

SMS is no longer considered a secure option for 2FA. Instead, one-time code provider, such as Google Authenticator or Okta Verify, should be used.

How Netwrix Can Help

Netwrix offers several solutions specifically designed to streamline and strengthen access and password management:

  • Netwrix Password Policy Enforcer makes it easy to create strong yet flexible password policies that enhance security and compliance without hurting user productivity or burdening helpdesk and IT teams.
  • Netwrix Password Reset enables users to safely unlock their own accounts and reset or change their own passwords, right from their web browser. This self-service functionality dramatically reduces user frustration and productivity losses while slashing helpdesk call volume.

FAQ

What is NIST Special Publication 800-63B?

NIST’s Digital Identity Guidelines (Special Publication 800-63B) provides reliable recommendations for identity and access management, including effective password policies.

Why does NIST recommend reducing password complexity requirements?

While requiring complex passwords makes them more difficult for attackers to crack, it also makes passwords harder for users to remember. To avoid frustrating lockouts, users tend to respond with behaviors like writing down their credentials on a sticky note by their desk or choosing to periodically reuse the same (or nearly the same) password — which increase security risks. Accordingly, NIST now recommends less stringent complexity requirements.

Source :
https://blog.netwrix.com/2022/11/14/nist-password-guidelines/

3 Overlooked Cybersecurity Breaches

Here are three of the worst breaches, attacker tactics and techniques of 2022, and the security controls that can provide effective, enterprise security protection for them.

#1: 2 RaaS Attacks in 13 Months#

Ransomware as a service is a type of attack in which the ransomware software and infrastructure are leased out to the attackers. These ransomware services can be purchased on the dark web from other threat actors and ransomware gangs. Common purchasing plans include buying the entire tool, using the existing infrastructure while paying per infection, or letting other attackers perform the service while sharing revenue with them.

In this attack, the threat actor consists of one of the most prevalent ransomware groups, specializing in access via third parties, while the targeted company is a medium-sized retailer with dozens of sites in the United States.

The threat actors used ransomware as a service to breach the victim’s network. They were able to exploit third-party credentials to gain initial access, progress laterally, and ransom the company, all within mere minutes.

The swiftness of this attack was unusual. In most RaaS cases, attackers usually stay in the networks for weeks and months before demanding ransom. What is particularly interesting about this attack is that the company was ransomed in minutes, with no need for discovery or weeks of lateral movement.

A log investigation revealed that the attackers targeted servers that did not exist in this system. As it turns out, the victim was initially breached and ransomed 13 months before this second ransomware attack. Subsequently, the first attacker group monetized the first attack not only through the ransom they obtained, but also by selling the company’s network information to the second ransomware group.

In the 13 months between the two attacks, the victim changed its network and removed servers, but the new attackers were not aware of these architectural modifications. The scripts they developed were designed for the previous network map. This also explains how they were able to attack so quickly – they had plenty of information about the network. The main lesson here is that ransomware attacks can be repeated by different groups, especially if the victim pays well.

“RaaS attacks such as this one are a good example of how full visibility allows for early alerting. A global, converged, cloud-native SASE platform that supports all edges, like Cato Networks provides complete network visibility into network events that are invisible to other providers or may go under the radar as benign events. And, being able to fully contextualize the events allows for early detection and remediation.

#2: The Critical Infrastructure Attack on Radiation Alert Networks#

Attacks on critical infrastructure are becoming more common and more dangerous. Breaches of water supply plants, sewage systems and other such infrastructures could put millions of residents at risk of a human crisis. These infrastructures are also becoming more vulnerable, and attack surface management tools for OSINT like Shodan and Censys allow security teams to find such vulnerabilities with ease.

In 2021, two hackers were suspected of targeting radiation alert networks. Their attack relied on two insiders that worked for a third party. These insiders disabled the radiation alert systems, significantly debilitating their ability to monitor radiation attacks. The attackers were then able to delete critical software and disable radiation gauges (which is part of the infrastructure itself).

Cybersecurity Breaches

“Unfortunately, scanning for vulnerable systems in critical infrastructure is easier than ever. While many such organizations have multiple layers of security, they are still using point solutions to try and defend their infrastructure rather than one system that can look holistically at the full attack lifecycle. Breaches are never just a phishing problem, or a credentials problem, or a vulnerable system problem – they are always a combination of multiple compromises performed by the threat actor,” said Etay Maor, Sr. Director of Security Strategy at Cato Networks.

#3: The Three-Step Ransomware Attack That Started with Phishing#

The third attack is also a ransomware attack. This time, it consisted of three steps:

1. Infiltration – The attacker was able to gain access to the network through a phishing attack. The victim clicked on a link that generated a connection to an external site, which resulted in the download of the payload.

2. Network activity – In the second phase, the attacker progressed laterally in the network for two weeks. During this time, it collected admin passwords and used in-memory fileless malware. Then on New Year’s Eve, it performed the encryption. This date was chosen since it was (rightfully) assumed the security team would be off on vacation.

3. Exfiltration – Finally, the attackers uploaded the data out of the network.

In addition to these three main steps, additional sub-techniques were employed during the attack and the victim’s point security solutions were not able to block this attack.

Cybersecurity Breaches

“A multiple choke point approach, one that looks horizontally (so to speak) at the attack rather than as a set of vertical, disjointed issues, is the way to enhance detection, mitigation and prevention of such threats. Opposed to popular belief, the attacker needs to be right many times and the defenders only need to be right just once. The underlying technologies to implement a multiple choke point approach are full network visibility via a cloud-native backbone, and a single pass security stack that’s based on ZTNA.” said Etay Maor, Sr. Director of Security Strategy at Cato Networks.

How Do Security Point Solutions Stack Up?#

It is common for security professionals to succumb to the “single point of failure fallacy”. However, cyber-attacks are sophisticated events that rarely involve just one tactic or technique which is the cause of the breach. Therefore, an all-encompassing outlook is required to successfully mitigate cyber-attacks. Security point solutions are a solution for single points of failure. These tools can identify risks, but they will not connect the dots, which could and has led to a breach.

Here’s Watch Out for in the Coming Months#

According to ongoing security research conducted by Cato Networks Security Team, they have identified two additional vulnerabilities and exploit attempts that they recommend including in your upcoming security plans:

1. Log4j#

While Log4j made its debut as early as December of 2021, the noise its making hasn’t died down. Log4j is still being used by attackers to exploit systems, as not all organizations have been able to patch their Log4j vulnerabilities or detect Log4j attacks, in what is known as “virtual patching”. They recommend prioritizing Log4j mitigation.

2. Misconfigured Firewalls and VPNs#

Security solutions like firewalls and VPNs have become access points for attackers. Patching them has become increasingly difficult, especially in the era of architecture cloudification and remote work. It is recommended to pay close attention to these components as they are increasingly vulnerable.

How to Minimize Your Attack Surface and Gain Visibility into the Network#

To reduce the attack surface, security professionals need visibility into their networks. Visibility relies on three pillars:

  • Actionable information – that can be used to mitigate attacks
  • Reliable information – that minimizes the number of false positives
  • Timely information – to ensure mitigation happens before the attack has an impact

Once an organization has complete visibility to the activity on their network they can contextualize the data, decide whether the activity witnessed should be allowed, denied, monitored, restricted (or any other action) and then have the ability to enforce this decision. All these elements must be applied to every entity, be it a user, device, cloud app etc. All the time everywhere. That is what SASE is all about.

Found this article interesting? Follow us on Twitter  and LinkedIn to read more exclusive content we post.

Source :
https://thehackernews.com/2023/02/3-overlooked-cybersecurity-breaches.html

The Definitive Browser Security Checklist

Security stakeholders have come to realize that the prominent role the browser has in the modern corporate environment requires a re-evaluation of how it is managed and protected. While not long-ago web-borne risks were still addressed by a patchwork of endpoint, network, and cloud solutions, it is now clear that the partial protection these solutions provided is no longer sufficient. Therefore, more and more security teams are now turning to the emerging category of purpose-built Browser Security Platform as the answer to the browser’s security challenges.

However, as this security solution category is still relatively new, there is not yet an established set of browser security best practices, nor common evaluation criteria. LayerX, the User-First Browser Security Platform, is addressing security teams’ need with the downable Browser Security Checklistthat guides its readers through the essentials of choosing the best solution and provides them with an actionable checklist to use during the evaluation process.

The Browser is The Most Important Work Interface and the Most Targeted Attack Surface #

The browser has become the core workspace in the modern enterprise. On top of being the gateway to sanctioned SaaS apps and other non-corporate web destinations, the browser is the intersection point between cloud\web environments and physical or virtual endpoints. This makes the browser both a target for multiple types of attacks, as well as a potential source of unintentional data leakage.

Some of these attacks have been around for more than a decade, exploitation of browser vulnerabilities or drive-by download of malicious files, for example. Others have gained recent momentum alongside the steep rise in SaaS adoption, like social engineering users with phishing webpages. Yet others leverage the evolution in web page technology to launch sophisticated and hard-to-detect modifications and abuse of browser features to capture and exfiltrate sensitive data.

Browser Security 101 – What is It That We Need to Protect?#

Browser security can be divided into two different groups: preventing unintended data exposure and protection against various types of malicious activity.

From the data protection aspect, such a platform enforces policies that ensure sensitive corporate data is not shared or downloaded in an insecure manner from sanctioned apps, nor uploaded from managed devices to non-corporate web destinations.

From the threat protection aspect, such a platform detects and prevents three types of attacks:

  • Attacks that target the browser itself, with the purpose of compromising the host device or the data that resides within the browser application itself, such as cookies, passwords, and others.
  • Attacks that utilize the browser via compromised credentials to access corporate data that resides in both sanctioned and unsanctioned SaaS applications.
  • Attacks that leverage the modern web page as an attack vector to target user’s passwords, via a wide range of phishing methods or through malicious modification of browser features.

How to Choose the Right Solution#

What should you focus on when choosing the browser security solution for your environment? What are the practical implications of the differences between the various offerings? How should deployment methods, the solution’s architecture, or user privacy be weighed in the overall consideration? How should threats and risks be prioritized?

As we’ve said before – unlike with other security solutions, you can’t just ping one of your peers and ask what he or she is doing. Browser security is new, and the wisdom of the crowd is yet to be formed. In fact, there’s an excellent chance that your peers are now struggling with the very same questions you are.

The Definitive Browser Security Platform Checklist – What it is and How to Use It#

The checklist (download it here) breaks down the high-level ‘browser security’ headline to small and digestible chunks of the concrete needs that need to be solved. These are brought to the reader in five pillars – deployment, user experience, security functionalities and user privacy. For each pillar there is a short description of its browser context and a more detailed explanation of its capabilities.

The most significant pillar, in terms of scope, is of course, the security functionalities one, which is divided into five sub-sections. Since, in most cases, this pillar would be the initial driver to pursuing browser security platform in the first place it’s worth going over them in more detail:

Browser Security Deep Dive#

The need for browser security platform typically arises from one of the following:

— Attack Surface Management: Proactive reduction of the browser’s exposure to various types of threats, eliminating adversaries’ ability to carry them out.

— Zero Trust Access: Hardening the authentication requirements to ensure that the username and password were indeed provided by the legitimate user and were not compromised.

— SaaS Monitoring and Protection: 360° visibility into all users’ activity and data usage within sanctioned and unsanctioned apps, as well as other non-corporate web destinations, while safeguarding corporate data from compromise or loss.

— Protection Against Malicious Web Pages: Real-time detection and prevention of all the malicious tactics adversaries embed in the modern web page, including credential phishing, downloading of malicious files and data theft.

— Secure 3rd Party Access and BYOD: Enablement of secure access to corporate web resources from unmanaged devices of both the internal workforce as well as external contractors and service providers.

This list enables anyone to easily identify the objective for their browser security platform search and find out the required capabilities for fulfilling it.

The Checklist – A Straightforward Evaluation Shortcut #

The most important and actionable part in the guide is the concluding checklist, which provides, for the first time, a concise summary of all the essential capabilities a browser security platform should provide. This checklist makes the evaluation process easier than ever. All you have to do now is test the solutions you’ve shortlisted against it and see which one scores the highest. Once you have all of them lined up, you can make an informed decision based on the needs of your environment, as you understand them.

Download the checklist here.

Found this article interesting? Follow us on Twitter  and LinkedIn to read more exclusive content we post.

Source :
https://thehackernews.com/2023/01/the-definitive-browser-security.html

Is Once-Yearly Pen Testing Enough for Your Organization?

Any organization that handles sensitive data must be diligent in its security efforts, which include regular pen testing. Even a small data breach can result in significant damage to an organization’s reputation and bottom line.

There are two main reasons why regular pen testing is necessary for secure web application development:

  • Security: Web applications are constantly evolving, and new vulnerabilities are being discovered all the time. Pen testing helps identify vulnerabilities that could be exploited by hackers and allows you to fix them before they can do any damage.
  • Compliance: Depending on your industry and the type of data you handle, you may be required to comply with certain security standards (e.g., PCI DSS, NIST, HIPAA). Regular pen testing can help you verify that your web applications meet these standards and avoid penalties for non-compliance.

How Often Should You Pentest?#

Many organizations, big and small, have once a year pen testing cycle. But what’s the best frequency for pen testing? Is once a year enough, or do you need to be more frequent?

The answer depends on several factors, including the type of development cycle you have, the criticality of your web applications, and the industry you’re in.

You may need more frequent pen testing if:

You Have an Agile or Continuous Release Cycle#

Agile development cycles are characterized by short release cycles and rapid iterations. This can make it difficult to keep track of changes made to the codebase and makes it more likely that security vulnerabilities will be introduced.

If you’re only testing once a year, there’s a good chance that vulnerabilities will go undetected for long periods of time. This could leave your organization open to attack.

To mitigate this risk, pen testing cycles should align with the organization’s development cycle. For static web applications, testing every 4-6 months should be sufficient. But for web applications that are updated frequently, you may need to test more often, such as monthly or even weekly.

Your Web Applications Are Business-Critical#

Any system that is essential to your organization’s operations should be given extra attention when it comes to security. This is because a breach of these systems could have a devastating impact on your business. If your organization relies heavily on its web applications to do business, any downtime could result in significant financial losses.

For example, imagine that your organization’s e-commerce site went down for an hour due to a DDoS attack. Not only would you lose out on potential sales, but you would also have to deal with the cost of the attack and the negative publicity.

To avoid this scenario, it’s important to ensure that your web applications are always available and secure.

Non-critical web applications can usually get away with being tested once a year, but business-critical web applications should be tested more frequently to ensure they are not at risk of a major outage or data loss.

Your Web Applications Are Customer-Facing#

If all your web applications are internal, you may be able to get away with pen testing less frequently. However, if your web applications are accessible to the public, you must be extra diligent in your security efforts.

Web applications accessible to external traffic are more likely to be targeted by attackers. This is because there is a greater pool of attack vectors and more potential entry points for an attacker to exploit.

Customer-facing web applications also tend to have more users, which means that any security vulnerabilities will be exploited more quickly. For example, a cross-site scripting (XSS) vulnerability in an external web application with millions of users could be exploited within hours of being discovered.

To protect against these threats, it’s important to pen test customer-facing web applications more frequently than internal ones. Depending on the size and complexity of the application, you may need to pen test every month or even every week.

You Are in a High-Risk Industry#

Certain industries are more likely to be targeted by hackers due to the sensitive nature of their data. Healthcare organizations, for example, are often targeted because of the protected health information (PHI) they hold.

If your organization is in a high-risk industry, you should consider conducting pen testing more frequently to ensure that your systems are secure and meet regulatory compliance. This will help protect your data and reduce the chances of a costly security incident.

You Don’t Have Internal Security Operations or a Pen testing Team#

This might sound counterintuitive, but if you don’t have an internal security team, you may need to conduct pen testing more frequently.

Organizations that don’t have dedicated security staff are more likely to be vulnerable to attacks.

Without an internal security team, you will need to rely on external pen testers to assess your organization’s security posture.

Depending on the size and complexity of your organization, you may need to pen test every month or even every week.

You Are Focused on Mergers or Acquisitions#

During a merger or acquisition, there is often a lot of confusion and chaos. This can make it difficult to keep track of all the systems and data that need to be secured. As a result, it’s important to conduct pen testing more frequently during these times to ensure that all systems are secure.

M&A also means that you are adding new web applications to your organization’s infrastructure. These new applications may have unknown security vulnerabilities that could put your entire organization at risk.

In 2016, Marriott acquired Starwood without being aware that hackers had exploited a flaw in Starwood’s reservation system two years earlier. Over 500 million customer records were compromised. This placed Marriott in hot water with the British watchdog ICO, resulting in 18.4 million pounds in fines in the UK. According to Bloomberg, there is more trouble ahead, as the hotel giant could “face up to $1 billion in regulatory fines and litigation costs.”

To protect against these threats, it’s important to conduct pen testing before and after an acquisition. This will help you identify potential security issues so they can be fixed before the transition is complete.

The Importance of Continuous Pen Testing#

While periodic pen testing is important, it is no longer enough in today’s world. As businesses rely more on their web applications, continuous pen testing becomes increasingly important.

There are two main types of pen testing: time-boxed and continuous.

Traditional pen testing is done on a set schedule, such as once a year. This type of pen testing is no longer enough in today’s world, as businesses rely more on their web applications.

Continuous pen testing is the process of continuously scanning your systems for vulnerabilities. This allows you to identify and fix vulnerabilities before they can be exploited by attackers. Continuous pen testing allows you to find and fix security issues as they happen instead of waiting for a periodic assessment.

Continuous pen testing is especially important for organizations that have an agile development cycle. Since new code is deployed frequently, there is a greater chance for security vulnerabilities to be introduced.

Pen testing as a service models is where continuous pen testing shine. Outpost24’s PTaaS (Penetration-Testing-as-a-Service) platform enables businesses to conduct continuous pen testing with ease. The Outpost24 platform is always up-to-date with an organization’s latest security threats and vulnerabilities, so you can be confident that your web applications are secure.

  • Manual and automated pen testing: Outpost24’s PTaaS platform combines manual and automated pen testing to give you the best of both worlds. This means you can find and fix vulnerabilities faster while still getting the benefits of expert analysis.
  • Provides comprehensive coverage: Outpost24’s platform covers all OWASP Top 10 vulnerabilities and more. This means that you can be confident that your web applications are secure against the latest threats.
  • Is cost-effective: With Outpost24, you only pay for the services you need. This makes it more affordable to conduct continuous pen testing, even for small businesses.

The Bottom Line#

Regular pen testing is essential for secure web application development. Depending on your organization’s size, industry, and development cycle, you may need to revise your pen testing schedule.

Once-a-year pen testing cycle may be enough for some organizations, but for most, it is not. For business-critical, customer-facing, or high-traffic web applications, you should consider continuous pen testing.

Outpost24’s PTaaS platform makes it easy and cost-effective to conduct continuous pen testing. Contact us today to learn more about our platform and how we can help you secure your web applications.

Found this article interesting? Follow us on Twitter  and LinkedIn to read more exclusive content we post.

Source :
https://thehackernews.com/2023/01/is-once-yearly-pen-testing-enough-for.html