I had this problem on a server for a while – when first launching PowerShell, it would take ~20 seconds or so to accept input. Also, when pressing tab to auto-complete a command, it would again take ~20 seconds to start, like it was freezing. These were one time problems when launching PowerShell, after that it would work fine until a new session was launched.
A lot of searching didn’t help me work it out, so I logged a Microsoft case. After a few task manager executable dumps, they worked out the delay was on a path I had in an environment variable. Somehow in my account’s user variable, I had a github desktop path that was mapping to a network share, using a PC name that was decommissioned (e.g. ;\\pcname\c$\Users\AdamFowler\AppData\Local\GitHubDesktop\bin.
I expect that this name was timing out, and PowerShell was waiting a while before giving up. In case you have the same symptoms as me, check the environment variables – user variables paths if it’s only your account affected, or the system variables if it’s all users. Click on the path value, then click edit, and remove anything that shoudn’t be there (take a backup of the text if you aren’t sure, it’s easy to put back in if you keep a copy).
To get to Environment Variables, depending on the OS version, get to System Properties, the Advanced tab, and then the Environment Variables button:
Hope that helps someone else with the same problem!
As per Microsoft Documentation , there’s Intune device limits, and Azure device limits. Intune / EndPoint Manager has a maximum of 15 devices, where Azure has a default of 20, but can be changed to a few different values, including ‘unlimited’.
To remove devices from a user, and admin should use Azure Active Directory and go to Users > Find the user > then under Manage, choose ‘Devices’. Any old device (check by the activity date) can be selected and deleted.
After removing enough devices here, you should be able to register the new device via the Intune Company Portal app again – and in my testing, this was next to instant.
Application security is the process of finding and fixing security vulnerabilities in applications for enhancing their security.
With application security, the goal is to prevent code or data within applications from getting hacked or stolen. Though this process was hardly popular a decade ago, application security has become a crucial part of today’s software development lifecycle.
Nowadays, it has become one of the top priorities for businesses, thanks to the ever-changing and ever-growing digital ecosystem.
Also, it has become one of the major challenges for software developers and security professionals since today’s software have become more complex than ever and cybercriminals are continuously improving their efforts and skills to find vulnerabilities and compromise applications.
That is, the report confirms that cybercriminals mostly target applications’ vulnerabilities to compromise an organization’s networks and systems and wreak havoc on their target organization. Moreover, the report predicts that this trend of attackers targeting web application vulnerabilities is not going away anytime soon. S
What made application security so lucrative to attackers?
According to The Increasing Risk to Enterprise Applications by Ponemon Institute, “Investment in application security is not commensurate with the risk. An average of 16 percent of the overall IT budget is dedicated to data protection and security. There is a significant gap between the level of application risk (33 percent of total risk) and what companies are spending to protect their applications (20 percent of annual spending in IT security). However, the level of risk to networks is much lower (18 percent) than the investment in network security (35 percent),” states the report about the investment vs. risk ratio of application security.
That means organizations are not doing enough to mitigate application security risks. The report states that 74 percent of respondents reported that it is difficult to prevent online attacks targeting application vulnerabilities because their organizations are unable to monitor and prevent attacks at the application level, unfortunately. And one of its major reasons is the shift to cloud computing, which resulted in the loss of control and visibility over business-critical apps, as reported by 81 percent of respondents. Moreover, the information technology industry quickly adopted remote working in 2020 due to COVID-19, which left decision-makers with no to little time for performing the security planning.
Nowadays, organizations are not restricted to one cloud provider, but they mostly opt for a multi-cloud architecture for their mission-critical applications.
The reason being this architecture provides better reliability and speed for their applications, however, it hampers its security because of its complexity. Also, the popularity of mobile applications has skyrocketed in recent years, making organizations of all sizes to launch mobile versions of their applications, and thus providing more attack surface to the hackers and increasing the probability of attacks.
How to maintain application security across many platforms?
First of all, organizations must follow application security best practices starting with the industry-leading practices around multi-cloud security. They must synchronize their policies and settings across their cloud setups, use multiple security policies (one per application or service).
Automate as much as possible, choose the right security tools, configure a monitoring strategy to keep track of all cloud setups, opt for efficient compliance tools, simplify security by bringing all controls under a single dashboard, and minimize point security solutions that do not integrate with each other or the all-in-one centralized dashboard.
Secondly, organizations should understand the threats of APIs. They must perform regular security testing of their APIs, monitor third-party applications using their APIs, follow the industry best practices for APIs, add solid support for authentication and authorization, double-secure the data at the backend like databases and data lakes, and opt for security tools and gateways for APIs.
With regular security testing of the codebase as well as third-party applications and libraries, organizations can decrease the chances of attacks on their apps.
Thirdly, organizations must secure their mobile applications from the ground up by writing secure code and encrypting all data on mobile devices.
As with any software, developers must cautiously utilize third-party libraries as open-source libraries can be extremely insecure and vulnerable, providing access to the apps in the hands of attackers, deploy proper authorization and authentication along with session handling, utilize the principle of least privilege, and opt for the best cryptography and security tools and techniques along with regular testing.
Lastly, organizations should understand the risk of bots.
In recent years, hackers have gained unprecedented resources for compromising millions if not billions of devices to perform their bidding. Though web application firewalls may offer crucial security capabilities to detect and prevent complex attacks, they are not enough against bot traffic. That is why businesses must opt for bot management tools to build a robust defense posture against bots and attacks like DDoS.
Such a basic thing, but great to see. As per this Forms Uservoice suggestion, Microsoft Forms now has a ‘shorten URL’ option. It’s still rolling out right now (March 2021) but it turned up in my tenants. You’ll find it under the Share menu, and then under ‘Send and collect responses’ :
The tick box is called ‘Shorten URL’:
Before ticking this box, the Forms URL for sharing looks like this:
Impersonation Protection in Microsoft Defender for Office 365 is part of the Anti-phishing policies, designed to take action if an external email comes in with a match, or near match, to the display name of an employee.
The actions you can take when a match is made are:
Redirect message to other email addresses
Move message to the recipient’s Junk Email folders
Quarantine the message
Deliver the message and add other addresses to the Bcc line
Delete the message before it’s delivered
Don’t apply any action
What I wanted to do, was deliver the message and add other addresses to the bcc line. This could be used to send a copy of the email to helpdesk for investigation, as Impersonation Protection tends to get a lot of false positives from services that like to use people’s actual names from emails they generate, or from people using a personal account to email other employees.
What I found was that the action was applied, but the email was then delivered to the Junk Email folder. If I wanted that to happen, I would have selected the ‘Move message to the recipient’s junk email folders’ option. After logging a case with Microsoft, I found out why.
Any time an email is detected as an Impersonation Protection, and the mail is still allowed to flow through, it will set the header as SCL 5. As per Office 365 standards, this will deliver the email to the recipient’s junk mail folder.
It makes the choices on what actions to take in the Impersonation Protection settings rather misleading; but there is one option that’s still reasonable – Quarantine the message. This should trigger a fairly quick quarantine digest to the recipient for review, allowing them to review and decide if it should be released. If released, it will then deliver to the Inbox rather than Junk Mail.