c# pdf viewer itextsharp : Change page order in pdf reader SDK control project wpf web page html UWP Windows%20Powershell%20in%20Action%202nd%20Edition92-part1552

890
CHAPTER 21
S
ECURITY
SECURITY
SECURITY
tools instead of trying to roll your own. We’ll spend a considerable amount of time 
on some of these tools later in this chapter.
21.1.2
Security: perception and reality
One last thing: Regardless of what computer security is or isn’t, sometimes it’s the per-
ception of security that matters most. Let’s take a look at a couple of stories that illus-
trate this.
The Danom virus
As we’ve discussed, PowerShell can be used to write scripts. It can be used to create, 
copy, and modify files. This means that, like any scripting or programming language, 
it can be used to write viruses, worms, and other malware. 
NOTE
The term malware is short for malicious software and is used to 
generally describe all forms of software (spyware, viruses, and so on) 
designed to cause damage in a computing environment. This may be 
the only definition in the security vocabulary that everybody agrees on. 
Or maybe not.
The fact that PowerShell could be used for this purpose didn’t go unnoticed in the 
malware community. In August 2005, a virus author created a proof-of-concept virus 
called Danom (Monad backwards). This virus script was essentially a port of existing 
virus code to the PowerShell language. The same virus code had previously been writ-
ten in a variety of other scripting languages. It didn’t take advantage of any vulnera-
bility in either the operating system or the language interpreter. It required explicit 
and significant user action to execute the virus code. In fact, all it did was demon-
strate that PowerShell was a decent scripting language. There wasn’t even a delivery 
vehicle. In other words, there was no way to distribute the malicious code. And with 
no mechanism to distribute the virus code, the threat was purely hypothetical.
This coding exercise was noticed by a security researcher, who then issued a bulle-
tin about it. This bulletin was picked up, first by the blogs and later by members of 
the popular press, without investigating the details of the situation. 
Because of the work that was going on with the next generation of Windows at 
the time (the rather ill-fated Vista release), the press called this the first Vista virus. 
The Microsoft security response team members responded by saying that it wasn’t a 
Vista virus because PowerShell wasn’t in the official list of features for Vista at that 
time. The press immediately turned this into “PowerShell cancelled due to virus 
threat.” None of this was true, of course, but it made a good headline and lots of peo-
ple, even inside Microsoft, believed the story. 
Out  of  all  of  this,  one  thing  that  was  gratifying  was  how  the  community 
responded to all this coverage. They reviewed the virus code and the security mea-
sures that the PowerShell team had designed into the product and saw that Danom
Change page order in pdf reader - re-order PDF pages in C#.net, ASP.NET, MVC, Ajax, WinForms, WPF
Support Customizing Page Order of PDF Document in C# Project
how to reorder pages in pdf preview; how to move pages within a pdf document
Change page order in pdf reader - VB.NET PDF Page Move Library: re-order PDF pages in vb.net, ASP.NET, MVC, Ajax, WinForms, WPF
Sort PDF Document Pages Using VB.NET Demo Code
how to reorder pages in pdf; reorder pages in pdf preview
S
ECURITY
MODELING
891
presented no significant threat. With the help of the community and some aggressive 
blogging,  the  tide  was  turned  and  people  realized  that  there was  no  threat.  All 
returned to normal, at least for a while.
The MSH/Cibyz worm
Almost exactly one year later, in August 2006, the 
MSH/C
ibyz worm was released. 
This was essentially the Danom code with some updates and bug fixes. 
NOTE
Between the first and second releases, the malware dictionary 
had been revised, so the second time around, the same code was reclas-
sified as a worm instead of a virus. It’s like being at a ball game listen-
ing to the guy handing out today’s program: “Programs! Programs! Get 
your programs! You can’t tell a worm from a virus without a program!”
This time, there was a delivery vehicle using one of the peer-to-peer networks. The 
story was picked up by the blogging community initially, but eventually a large secu-
rity software vendor issued a press release with an inflammatory title. The body of the 
release, essentially said, “There’s nothing to see here. These aren’t the droids you’re 
looking  for. Please move  along.” But it  still generated discussion and rumors for 
about a week.
The moral of the story is that it pays to investigate security alerts rather than just 
react to headlines. Without being properly informed, it’s impossible to plan appro-
priate action, and planning is the key to establishing a secure environment. Because 
one of the best tools for planning is security modeling, we’ll spend the next couple of 
sections discussing these techniques.
21.2
S
ECURITY
MODELING
In this section, we’ll briefly review some of the theories and concepts that have been 
developed to help build secure systems. We’ll review the concepts of threats, vulnera-
bilities, and attacks. We’ll also cover the basics of threat modeling and why it’s impor-
tant. Note that this topic is an active and rapidly changing area of research. Theories 
and approaches are postulated, applied, and refuted over very short periods of time. 
The theoretical material we present in this section may even be obsolete by the time 
you read this book. Still, having an awareness of the approaches that are being devel-
oped for building secure systems is always beneficial.
21.2.1
Introduction to threat modeling
Threat modeling is a systematic approach to identifying and categorizing threats to a 
system. So what does that mean? A model is a simplified representation of a system with 
unnecessary or unimportant details left out. By building a model, you can focus on the 
details that matter and ignore the ones that don’t. Modern computer systems are too 
complex to address every detail. You have to focus your attention on what matters most. 
VB.NET Word: Change Word Page Order & Sort Word Document Pages
Note: if you are trying to change the order of a you want to see other VB.NET Word document editing controls, please read this Word reading page which has
pdf change page order online; how to change page order in pdf acrobat
C# PDF File & Page Process Library SDK for C#.net, ASP.NET, MVC
PDF Document; Remove Password from PDF; Change PDF Permission Settings. Page: Insert PDF pages; VB.NET Page: Delete PDF VB.NET Annotate: PDF Markup & Drawing. XDoc
change page order pdf preview; change page order pdf
892
CHAPTER 21
S
ECURITY
SECURITY
SECURITY
Let’s look at some more definitions. A threat to a system is a potential event that 
will have unpleasant or undesirable consequences. A vulnerability is a weakness in the 
design or implementation of a system that an attacker may exploit to cause one of 
these undesirable events. An attack is when someone takes advantage of these vulner-
abilities to gain some advantage that they aren’t otherwise permitted to have. 
Back to modeling. The point of a model is to have a formal approach for looking 
at threats and vulnerabilities with the idea of defeating attacks. This is important 
because you can quite literally spend the rest of eternity trying to guard a system 
against things that don’t matter. If you don’t have a way of focusing your efforts, the 
result will be a solution that will be useless at best. 
21.2.2
Classifying threats using the STRIDE model
STRIDE
is  a  well-known  threat  classification  model. 
STRIDE
is an  acronym  for 
Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and 
Elevation of Privilege. It’s a way to categorize all the significant threats to a system. 
Remember—a threat is something the attacker wants to happen, which means it’s 
something you don’t want. The idea is that if you model all of the 
STRIDE
threat 
classifications, you have a decent chance of covering the most important areas. Table
21.1 explains each of the components of 
STRIDE
.
For  more  information  on 
STRIDE
 see  Writing  Secure  Code,  Second  Edition,  by 
Michael Howard and David LeBlanc (Microsoft Press, 2004).
Now that you have a system for understanding and classifying threats, let’s look at 
the remaining pieces you need to build the threat model.
Table 21.1 The threat classifications in the STRIDE model
Threat classification
Explanation
Spoofing identity
Spoofing refers to various ways of assuming the identity of another user for 
the duration of a task.
Tampering with data
Tampering means changing data. Note that this doesn’t imply information 
disclosure—simple corruption may be all that’s achieved.
Repudiation
From an attacker’s perspective, repudiation essentially means covering your 
tracks. A particular act can’t be traced or attributed to the source of the act.
Information disclosure Information disclosure is allowing unauthorized persons access to sensitive 
information such as credit card numbers and passwords.
Denial of service
A denial-of-service (DoS) attack involves some form of resource exhaustion. 
It could be network bandwidth, CPU cycles, or disk space. The problem 
with DoS attacks is that they’re easy to launch anonymously and 
sometimes it’s difficult to tell if it’s actually an attack or that $2.99 
special that you just announced on your website that’s causing a sudden 
burst of network traffic.
Elevation of privilege
In elevation of privilege attacks, an unprivileged user or process gains privi-
leged access.
C# Word - Process Word Document in C#
various Word document processing implementations using C# demo codes, such as add or delete Word document page, change Word document pages order, merge or
rearrange pdf pages online; reorder pages pdf file
VB.NET PDF File & Page Process Library SDK for vb.net, ASP.NET
VB.NET PDF - How to Modify PDF Document Page in VB.NET. VB.NET Guide for Processing PDF Document Page and Sorting PDF Pages Order.
reorder pages in pdf reader; pdf move pages
S
ECURITY
MODELING
893
21.2.3
Security basics: threats, assets, and mitigations
There are three parts to building a security model: threats, assets, and mitigations. We 
talked  about  threats in  the  previous  section.  Assets  are  things that  motivate  the 
attacker to launch an attack. These assets may be things that are of direct value, such 
as credit card numbers or other financial information. They may also be of indirect 
value, such as code execution. This is an asset because once you have the ability to 
execute code on a machine, you can use these resources to do things such as send 
spam or execute distributed 
D
o
S
attacks against other targets. 
Mitigation is what you’re doing to mitigate those threats. The standard definition 
of mitigation is to cause something to become less harsh or severe. I use this term 
instead of prevent because it may well be that the activity you’re mitigating is neces-
sary;  for  example,  the ability to  execute  code  in  PowerShell  can’t be  prevented, 
because that’s its purpose. But you want to allow only authorized users to be able to 
execute approved scripts. The threat of unauthorized script execution is mitigated 
through a variety of approaches we’ll describe later in this chapter. Let’s look at a few 
things you should keep in mind when securing a system.
Avoid lawn gnome mitigation
There’s a tendency, when trying to mitigate problems or otherwise reduce the attack 
surface of a system, to focus on reducing attacks in a particular area instead of looking 
at the system as a whole. This approach can add complexity to the system without 
increasing security. This approach is known as lawn gnome mitigation. The story goes 
like this. You hire a security consultant to secure your home. He drives up to your 
house, parks, gets out, and stands on the sidewalk looking at the house. After a while, 
he says that he sees where the vulnerability lies. He goes to the trunk of his car, takes 
out a ceramic lawn gnome (as illustrated in figure 21.1), and places it on the lawn 
between himself and the front door of the house. “I’ve mitigated the threat,” he says. 
“That will be $2,000 please.” 
Figure 21.1 A brave and noble lawn gnome protecting a home in Kitchener, Ontario, 
Canada. Hopefully it didn’t cost the owner $2,000.
C# PowerPoint - Sort PowerPoint Pages Order in C#.NET
control, developers can swap or adjust the order of all or several PowerPoint document pages, or just change the position of certain one PowerPoint page in an
reorder pages in pdf; rearrange pdf pages
C# Word - Sort Word Pages Order in C#.NET
library control, developers can swap or adjust the order of all or several Word document pages, or just change the position of certain one Word page in an
reorder pages in a pdf; how to move pages in a pdf
894
CHAPTER 21
S
ECURITY
SECURITY
SECURITY
Has your high-priced security consultant mitigated a threat? As a matter of fact, he 
has. A burglar trying to break into the house, who crosses the lawn at that exact spot, 
will now trip over a lawn gnome. Of course, the burglar could go around it, or come 
at the house from a different direction. In fact, your house isn’t any safer, and you have 
an ugly ceramic statue in the middle of your lawn that you have to mow around. 
NOTE
There’s a variation of this approach that’s considered legiti-
mate, sometimes called “picket-fence” mitigation. A picket fence has 
holes in it, so you put another one behind it. And if there are still holes 
then you keep adding fences until there are no more holes. This is 
equivalent to dumping truckloads of lawn gnomes on your property 
until  the  house  is  surrounded  by  a  30-foot-high  wall  of  ceramic 
gnomes. It’ll work, but it’s not very attractive.
The moral of this story is that, when securing a system, don’t add unnecessary or 
inappropriate checks. You have to look at the system as a whole. This is particularly 
true when writing code. The more lawn gnomes you add, the more code you add to 
the system. Each new line of code introduces new possibilities for errors, and these 
errors can, in turn, become additional vulnerabilities.
Blacklisting/whitelisting
Short and sweet—blacklisting is saying who’s bad and whitelisting is saying who’s 
good. In general, whitelisting is preferred. Assume that the world is bad and you only 
trust people you know. This method is inherently the most secure approach to use 
with PowerShell. The number of people you trust to give you scripts to run is much 
smaller than the number of people you don’t trust to run scripts. PowerShell supports 
the use of script signing to verify the identity of a script publisher and also validate 
the integrity of a published script. (Signing is discussed at length in section 21.4.)
Whitelisting  is also an approach  that should  be used when constructing  con-
strained remoting sessions, as discussed in chapter 13, section 13.2.5. A constrained 
session should only expose the commands that are needed and all others should be 
marked private by default.
Authentication, authorization, and roles
Authentication  is  verifying  the  identity  of  the  user.  Authorization  is  determining 
whether the user is authorized to perform an action. Roles are groupings of activities 
for which authorization can be  granted.  Grouping  multiple activities  into a  role 
makes it easier to manage authorization. When users are assigned a particular role, 
they’re automatically authorized to perform all the activities associated with that role. 
PowerShell depends on the operating system for authentication and authorization 
(see section 13.1.4). For role-based access control 
(RBAC)
in PowerShell v2, through 
remoting and constrained sessions it’s possible to implement role-based mechanisms, 
though there are some significant limitations. A PowerShell script operates with the
C# PDF: C# Code to Process PDF Document Page Using C#.NET PDF
Enable C#.NET developers to change the page order of source PDF document file; Allow C#.NET developers to add image to specified area of source PDF document
how to reverse page order in pdf; how to change page order in pdf document
C# PDF Page Rotate Library: rotate PDF page permanently in C#.net
Empower C# Users to Change the Rotation Angle of PDF File DLLs for PDF Page Rotation in C#.NET Project. In order to run the sample code, the following steps
move pages in pdf reader; how to rearrange pdf pages reader
S
ECURITY
MODELING
895
capabilities associated with the security token of the user who’s running the script. 
This means that the remoting mechanism can’t grant the user any more privileges 
than they’d normally have. It can only restrict the set of operations they can perform.
Input validation
The rule is that you must validate any input received from outside your script. In 
scripting, this is the second most important rule for writing secure scripts. (The most 
important rule is “Don’t run unknown or untrusted scripts.”) 
Most scripting environments have the ability to dynamically compile and execute 
code (this is one of the things that makes them dynamic languages). It’s tempting to 
use this capability to simplify your code. Say the user needs to do some arithmetic 
calculations in a script. In PowerShell, you could just pass this code directly to the 
Invoke-Expression
cmdlet and let it evaluate the expression:
PS (1) > $userInput = "2+2"
Now use 
Invoke-Expression
to execute the command:
PS (2) > Invoke-Expression $userInput 
4
Wasn’t that easy? But what if the user types the following?
PS (3) > $userInput = "2+2; 'Hi there'"
PS (4) > Invoke-Expression $userInput 
Hi there
It still executed the calculation, but it also executed the code after the semicolon. In 
this example, it was a harmless statement. But it might have been something like
$userInput = "2+2; del –rec –force c:\"
If this statement were executed, it’d try to delete everything on your C: drive…which 
would be bad.
There are other places where you need to do input validation. If the user is sup-
plying a path, you should make sure that it’s a path that the user should have access 
to. For example:
$userInput = "mydata.txt"
Get-Content $userInput
This fragment of script will return the contents of the file mydata.txt from the cur-
rent directory. This is what the script author intended. But because the script isn’t 
doing any path checking, the user could have specified a path like
$userInput = "..\bob_dobbs\mydata.txt"
in which case they might get the contents of another user’s file. Suppose instead, the 
script were written as
PS (1) > $userinput = "..\bob_dobbs\mydata.txt"
PS (2) > $safePath = Join-Path . `
896
CHAPTER 21
S
ECURITY
SECURITY
SECURITY
>> (Split-Path -Leaf $userInput) 
>>
PS (3) > $safePath 
.\mydata.txt
Then, despite providing a relative path, users can still only get their own data. Alter-
natively, you may wish to generate an error message explaining that it’s an invalid file-
name:
PS (5) > if (Split-Path -Parent $userInput) { 
>> "Invalid file name: $userInput" 
>> } 
>>
Invalid file name: ..\bob_dobbs\mydata.txt
But you need to be careful with this; you may inadvertently leak information about 
the system through the error message.
NOTE
People sometimes find it hard to understand why this is an 
issue. Let’s look at an example. Say you’re logging into a system. If you 
enter a username and password and the system responds with “invalid 
account” if the username is wrong and “invalid password” if the pass-
word is wrong, the attacker now has a way of finding out whether an 
account name is valid. In a sense, they’ve won half the battle.
You need to balance being friendly to the user with maintaining a secure system. So 
even in quite simple systems, it’s tricky to get this kind of thing right. 
Code injection
Code injection is closely related to the input validation. In fact, the first couple of 
examples that we looked at in the input validation section are code injection attacks. 
When you’re writing PowerShell code, any use of 
Invoke-Expression
is suspect. 
There  are  usually  other  ways  of  doing  the  same  thing  that  don’t  require  using 
Invoke-Expression
. But there are other ways of injecting code into a PowerShell 
session. Scripts are the most obvious one. Every time a script is called, the script is 
loaded, parsed, and executed. Not only must you not execute scripts from unknown 
sources, you must make sure that no one can tamper with your own scripts. In the 
next section, we’ll go over the features in PowerShell for doing exactly that. 
Because PowerShell exists in mixed-language environments, you also need to be 
careful with other types of code injection attacks. The most common example is 
SQL 
injection attacks. This is the classic attack in the web application world. The basic 
attack mechanism is the same—nonvalidated user input is used to construct a 
SQL 
query. This query is then passed to the database and bad things happen. The query is 
being  executed on behalf of the user,  so  there may be  an information disclosure 
attack. The query may delete data from the database, in which case you’re looking at 
D
o
S
attack.
S
ECURING
THE
P
OWER
S
HELL
ENVIRONMENT
897
Even more common in the PowerShell environment is the use of languages such 
as 
VBS
cript and/or 
cmd.exe
batch scripts. All these file types represent opportunities 
for code injection.
At this point, we’ve covered the basic principles for creating a secure computing 
environment. Let’s take a look at the features in PowerShell that were designed to 
support these principles.
21.3
S
ECURING
THE
P
OWER
S
HELL
ENVIRONMENT
The whole point of PowerShell is to execute scripts that automate system manage-
ment tasks. As a consequence, there’s no such thing as an inherently safe PowerShell 
script. PowerShell has no concept of sandboxing; that is, executing in a safe restricted 
environment.  You  must  treat  all  PowerShell  scripts  as  if  they  were  executables. 
Because of this, when PowerShell is installed, it does a number of things to be secure 
by default. In this section, we’ll go over these features.
21.3.1
Secure by default
First,  we’ll  go  over  the  elements  of  the  PowerShell  installation  process  that  are 
intended to meet the requirement that it be secure by default. Secure by default means 
that simply installing PowerShell on a system shouldn’t introduce any security issues.
Notepad, the default file association for PowerShell 
File association is the way Windows figures out what application to launch as the 
default handler for files having a particular extension. For many scripting languages, 
the default association launches the interpreter for that language. This has led to many 
virus outbreaks. With PowerShell, the default file association for the .ps1 extension 
launches an editor: 
notepad.exe
in version 1 and 
powershell_ise.exe
in version 2. 
This means that if an attacker does manage to get a script onto your computer and you 
accidentally double-click on this script, instead of executing the script it will open in 
Notepad, at which point you can review the hacker’s code, or just delete the script.
Remoting is disabled by default
PowerShell remoting is disabled by default. Explicit action by a privileged user is 
required to enable remoting, and even after it has been enabled, the default remoting 
configurations are set up so that only members of the local Administrators group can 
access the configuration.
No execution of scripts by default
PowerShell is installed in such a way that it won’t run scripts by default and can only 
be used as an interactive command interpreter.
Before scripts can be run, the user has to take explicit action to change the execu-
tion policy for PowerShell to allow script execution. In the default configuration, the
898
CHAPTER 21
S
ECURITY
SECURITY
SECURITY
only  way  to  execute  code  is  if  the  user  manually  starts  PowerShell  and  types 
commands in at the prompt. 
So PowerShell is secure by default because it doesn’t do much of anything. Now 
let’s see how to make it useful by enabling script execution. But before you do that, 
you should know where the scripts we’re running are coming from. Like most shells, 
PowerShell uses the 
$ENV:PATH
environment variable to find commands. The use of 
this variable has security implications, so we’ll review those first before we talk about 
how to enable scripting.
Managing the command path
A common local attack vector involves the 
$ENV:PATH
and 
$ENV:PATHEXT
environ-
ment variables. These variables control where commands are found and which files 
are considered to be executable. The 
$ENV:PATHEXT 
variable lists the extensions of 
all of the file types that PowerShell will try to execute directly through the 
Create-
Process()
API
. The 
$ENV:PATH
variable controls what directories PowerShell will 
look in when it searches for external commands. If an attacker can compromise these 
variables or any of the files or directories that they reference, the attacker can use a 
“Trojan Horse” attack—making something dangerous appear harmless.
NOTE
Okay, who thinks a 20-foot-high wooden horse looks harm-
less? If you saw a 20-foot wooden horse appear in your driveway, would 
you say “Oh, look dear, let’s bring this giant wooden horse that we’ve 
never seen before into our house. Perhaps it will be our pet. I’ve always 
wanted a giant wooden horse as a pet! What could possibly go wrong?”
The most important mitigation for this type of attack is to not include the current 
directory in your command search path. This is the default behavior in PowerShell. 
Omitting the current directory in your search path guards against the situation where 
you 
cd
into an untrusted user’s directory and then execute what you think is a trusted 
system command such as 
ipconfig
. If you execute commands out of the current 
directory and the user had placed a Trojan 
ipconfig
command in this directory, 
their command would execute with all the privileges you have as a user. Not a good 
thing. In general, it’s best to leave the current path out of 
$ENV:PATH
.
There’s one other thing you should consider in this situation. The 
cmd.exe
inter-
preter does execute out of the current directory, so if you run a 
cmd
script from 
PowerShell in an untrusted directory, there’s a risk that the batch file could be com-
promised by Trojan programs.
21.3.2
Enabling scripting with execution policy
When PowerShell is installed, script execution is disabled by default. Script execution 
is controlled by the PowerShell execution policy setting. It’s important to understand 
what the execution policy is intended to do. It isn’t intended to prevent people from
S
ECURING
THE
P
OWER
S
HELL
ENVIRONMENT
899
using PowerShell—even in restricted mode it’s still possible to use PowerShell interac-
tively. The goal of the execution policy mechanism is to reduce the ways that Power-
Shell can be exploited by an attacker, allowing a user to operate more securely. It does 
so by preventing unintended execution of unknown and potentially malicious scripts. 
We’ll look at the various modes you can set execution policy to in the next section.
NOTE
When reviewing this chapter, I stumbled across a question on 
a technical  help  site.  The  poster  was  asking  for  help  converting a 
PowerShell script to 
VBS
cript. This was being done for “security rea-
sons.” When someone asked what the security issue was, the poster 
responded that they felt that it was necessary to keep their execution 
policy set to a very restrictive mode for fear of remote code execution 
attacks. The perception was that 
VBS
cript was somehow safer because 
it couldn’t be restricted. In essence, because there was a knob for Power-
Shell but not 
VBS
cript, 
VBS
cript had to be less dangerous. Although 
there might be a grain of truth to this (
VBS
cript has been around lon-
ger so, in theory, the ecosystem is more attuned to its potential security 
issues) in practice, they’re pretty much equally dangerous. PowerShell 
is just less easy to exploit by default. 
Choosing an execution policy setting
PowerShell v1 defined four execution policies: 
Restricted
AllSigned
Remote-
Signed
 and 
Unrestricted
. PowerShell  v2 introduced  two  new  policy  settings: 
Bypass
and 
Undefined
. The details of these policies are shown in table 21.2.
Table 21.2 Descriptions of the various execution policies
Policy
Description
Restricted
This is the default execution policy upon installation. When this policy is in 
effect, script execution is disabled. This includes script modules, profile files 
and types, and format files. PowerShell itself isn’t disabled and may still be 
used as an interactive command interpreter. Although this is the most secure 
policy, it severely impacts your ability to use PowerShell for automation.
AllSigned
When the execution policy is AllSigned, scripts can be executed but they 
must be Authenticode-signed before they’ll run. When running a signed script, 
you’ll be asked if you want to trust the signer of the script. Section 21.4 covers 
the details of script signing. AllSigned is still a secure policy setting, but it 
makes script development difficult. In an environment where scripts will be 
deployed rather than created, this is the best policy.
RemoteSigned
RemoteSigned requires that all scripts that are downloaded from a remote 
location be Authenticode-signed before they can be executed. Note that this 
depends on whether the application doing the download marks the script as 
coming from a remote location. Not all applications do this. Anything down-
loaded by Internet Explorer 6.0 or above, Outlook, or Outlook Express will be 
properly marked. RemoteSigned is the minimum recommended execution 
policy setting. It’s the best policy setting for script development.
Documents you may be interested
Documents you may be interested